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Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3 GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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Scope 



The present document provides an overview and overall description of the E-UTRAN radio interface protocol 
architecture. Details of the radio interface protocols will be specified in companion specifications of the 36 series. 



References 



The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including 
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same 
Release as the present document. 

[1] 3GPP TR 21.905: "Vocabulary for 3GPP Specifications". 

[2] 3GPP TR 25.913: "Requirements for Evolved UTRA (E-UTRA) and Evolved UTRAN (E- 

UTRAN)" 

[3] 3GPP TS 36.201 : "Evolved Universal Terrestrial Radio Access (E-UTRA); Physical layer; 

General description". 

[4] 3GPP TS 36.21 1 Evolved Universal Terrestrial Radio Access (E-UTRA); Physical Channels and 

Modulation . 

[5] 3GPP TS 36.212 Evolved Universal Terrestrial Radio Access (E-UTRA); Multiplexing and 

channel coding . 

[6] 3GPP TS 36.213 Evolved Universal Terrestrial Radio Access (E-UTRA); Physical layer 

procedures 

[7] 3GPP TS 36.214 Evolved Universal Terrestrial Radio Access (E-UTRA); Physical layer; 

Measurements 



3 Definitions, symbols and abbreviations 

3.1 Definitions 

For the purposes of the present document, the following terms and definitions apply. 

Carrier frequency: center frequency of the cell. 

MBMS-dedicated cell: cell dedicated to MBMS transmission. 

Frequency layer: set of cells with the same carrier frequency. 

Handover: procedure that changes the serving cell of a UE in RRC_CONNECTED. 

Unicast/MBMS-mixed cell: cell supporting both unicast and MBMS transmissions. 
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3.2 



Abbreviations 



For the purposes of the present document, the abbreviations given in TR 21.905 [1] and the following apply. An 
abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in 
TR 21.905 [1]. 

ACK Acknowledgement 

ACLR Adjacent Channel Leakage Ratio 

AM Acknowledge Mode 

AMBR Aggregate Maximum Bit Rate 

ARQ Automatic Repeat Request 

AS Access Stratum 

BCCH Broadcast Control Channel 

BCH Broadcast Channel 

C/I Carrier-to-interference Power Ratio 

CAZAC Constant Amplitude Zero Auto-Correlation 

CMC Connection Mobility Control 

CP Cyclic Prefix 

C-plane Control Plane 

CQI Channel Quality Indicator 

CRC Cyclic Redundancy Check 

DCCH Dedicated Control Channel 

DL Downlink 

DRX Discontinuous Reception 

DTCH Dedicated Traffic Channel 

DTX Discontinuous Transmission 

eNB E-UTRAN NodeB 

EPC Evolved Packet Core 

E-UTRA Evolved UTRA 

E-UTRAN Evolved UTRAN 

FDD Frequency Division Duplex 

FDM Frequency Division Multiplexing 

GERAN GSM EDGE Radio Access Network 

GNSS Global Navigation Satellite System 

GSM Global System for Mobile communication 

GBR Guaranteed Bit Rate 

HARQ Hybrid ARQ 

HO Handover 

HSDPA High Speed DownHnk Packet Access 

ICIC Inter-Cell Interference Coordination 

IP Internet Protocol 

LB Load Balancing 

LCR Low Chip Rate 

LTE Long Term Evolution 

MAC Medium Access Control 

MBMS Multimedia Broadcast Multicast Service 

MBR Maximum Bit Rate 

MCCH Multicast Control Channel 

MCS Modulation and Coding Scheme 

MIMO Multiple Input Multiple Output 

MME Mobility Management Entity 

MTCH MBMS Traffic Channel 

NACK Non- Acknowledgement 

NAS Non- Access Stratum 

OFDM Orthogonal Frequency Division Multiplexing 

OFDMA Orthogonal Frequency Division Multiple Access 

PA Power Amplifier 

PAPR Peak-to-Average Power Ratio 

PBR Prioritised Bit Rate 

PCCH Paging Control Channel 

PDCP Packet Data Convergence Protocol 
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PDU Packet Data Unit 

PHY Physical layer 

PLMN Public Land Mobile Network 

PRB Physical Resource Block 

PSC Packet Scheduling 

QAM Quadrature Amplitude Modulation 

QoS Quality of Service 

RAC Radio Admission Control 

RACH Random Access Channel 

RAT Radio Access Technology 

RB Radio Bearer 

RBC Radio Bearer Control 

RF Radio Frequency 

RLC Radio Link Control 

RNL Radio Network Layer 

ROHC Robust Header Compression 

RRC Radio Resource Control 

RRM Radio Resource Management 

RU Resource Unit 

S 1 -MME S 1 for the control plane 

S 1 -U S 1 for the user plane 

SAE System Architecture Evolution 

SAP Service Access Point 

SC-FDMA Single Carrier - Frequency Division Multiple Access 

SCH Synchronization Channel 

SDMA Spatial Division Multiple Access 

SDU Service Data Unit 

SEN Single Frequency Network 

SU Scheduling Unit 

TA Tracking Area 

TB Transport Block 

TCP Transmission Control Protocol 

TDD Time Division Duplex 

TM Transparent Mode 

TNL Transport Network Layer 

TTI Transmission Time Interval 

UE User Equipment 

UL Uplink 

UM Un-acknowledge Mode 

UMTS Universal Mobile Telecommunication System 

U-plane User plane 

UTRA Universal Terrestrial Radio Access 

UTRAN Universal Terrestrial Radio Access Network 

VRB Virtual Resource Block 

X2-C X2-Control plane 

X2-U X2-User plane 



Overall architecture 



The E-UTRAN consists of eNBs, providing the E-UTRA user plane (PDCP/RLC/M AC/PHY) and control plane (RRC) 
protocol terminations towards the UE. The eNBs are interconnected with each other by means of the X2 interface. The 
eNBs are also connected by means of the SI interface to the EPC (Evolved Packet Core), more specifically to the MME 
(Mobility Management Entity) by means of the SI -MME and to the SAE Gateway by means of the Sl-U. The SI 
interface supports a many-to-many relation between MMEs / SAE Gateways and eNBs. 

The EUTRAN architecture is illustrated in Figure 4 below. 
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Figure 4: Overall Architecture 

4.1 Functional Split 

The eNB hosts the following functions: 

- Functions for Radio Resource Management: Radio Bearer Control, Radio Admission Control, Connection 
Mobility Control, Dynamic allocation of resources to UEs in both uplink and downlink (scheduling); 

- IP header compression and encryption of user data stream; 

- Selection of an MME at UE attachment; 

NOTE: it is assumed, that at UE attachment, firstly the MME is involved, i.e. actually the MME is selected. 

- Routing of User Plane data towards S AE Gateway; 

NOTE: it is FES which node actually establishes the User Plane tunnel. 

NOTE: it is FES whether User Plane tunnel establishment takes place together with the RRC activation. 

- Scheduling and transmission of paging messages (originated from the MME); 

- Scheduling and transmission of broadcast information (originated from the MME or O&M); 
Measurement and measurement reporting configuration for mobility and scheduling. 

The MME hosts the following functions: 

- Distribution of paging messages to the eNBs; 

- Security control; 

- Idle state mobility control; 

- SAE bearer control; 

- Ciphering and integrity protection of NAS signalling. 
The SAE Gateway hosts the following functions: 

- Termination of U-plane packets for paging reasons (FES); 

- Switching of U-plane for support of UE mobility. 



ETSI 



3GPP TS 36.300 version 8.0.0 Release 8 



13 



ETSI TS 136 300 V8.0.0 (2007-03) 



This is summarized on the figure below where yellow boxes depict the logical nodes, white boxes depict the functional 
entities of the control plane and blue boxes depict the radio protocol layers. 

NOTE: it is assumed that a logical E-UTRAN node in addition to the eNB is not needed for RRM purposes. 

Moreover, due to the different usage of inter-cell RRM functionalities, each inter-cell RRM functionality 
should be considered separately in order to assess whether it should be handled in a centralised manner or 
in a distributed manner. 

NOTE: MBMS related functions in E-UTRAN are described separately in subclause 15. 
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Figure 4.1: Functional Split between E-UTRAN and EPC 



4.2 



Interfaces 



4.2.1 S1 Interface 



4.2.2 X2 Interface 



4.3 



Radio Protocol architecture 



In this subclause, the radio protocol architecture of E-UTRAN is given for the user plane and the control plane. 

4.3.1 User plane 

The figure below shows the protocol stack for the user-plane, where PDCP, RLC and MAC sublayers (terminated in 
eNB on the network side) perform the functions listed in subclause 6, e.g. header compression, ciphering, scheduling, 
ARQ and HARQ; 
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Figure 4.3.1 : User-plane protocol stack 

4.3.2 Control plane 

The figure below shows the protocol stack for the control-plane, where: 

- RLC and MAC sublayers (terminated in eNB on the network side) perform the same functions as for the user 
plane; 

RRC (terminated in eNB on the network side) performs the functions listed in subclause 7, e.g.: 

- Broadcast; 

- Paging; 

- RRC connection management; 

- RB control; 
Mobility functions; 

- UE measurement reporting and control. 

NAS control protocol (terminated in MME on the network side) performs among other things: 

- SAE bearer management; 

- Authentication; 
LTE_IDLE mobility handling; 

- Paging origination in LTE_IDLE; 

- Security control. 

NOTE: the NAS control protocol is not covered by the scope of this TS and is only mentioned for information. 
Note: It is FES whether PDCP is part of the control plane. 
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Figure 4.3.2: Control-plane protocol stack 
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Physical Layer for E-UTRA 



The generic frame structure is illustrated in Figure 5.1-1. Each 10 ms radio frame is divided into ten equally sized sub- 
frames. Each sub-frame consists of two equally sized slots. Each sub-frame can be assigned for either downlink or 
uplink transmission [there are certain restrictions in the assignment as the first and sixth sub-frame of each frame 
include the downlink synchronization signals^ 



#0 


#1 


#2 



#18 


#19 



slot 



Sub- frame 



One radio frame = 10ms 



Figure 5.1-1 : Generic frame structure 

In addition, for coexistence with LCR-TDD, an alternative frame structure illustrated in Figure 5.1-2 is also supported 
when operating E-UTRA in TDD mode. 



-One radio frame = 10ms- 



#0 #1 #2 


iG, m m m 


DwPTS 


UpPTS 





Guard period 



Figure 5.1-2: alternative frame structure 



5.1 



Downlink Transmission Scheme 



5.1 .1 Basic transmission scheme based on OFDM 

The downlink transmission scheme is based on conventional OFDM using a cyclic prefix. The OFDM sub-carrier 
spacing is Zlf = 15 kHz. 12 consecutive sub-carriers during one slot correspond to one downlink resource block. In the 
frequency domain, the number of resource blocks, Nrb, can range from NRB-min = 6 to NRB-max = [1 10]- 

In addition there is also a reduced sub-carrier spacingz1//o,;i, = 7.5 kHz, only for MB MS -dedicated cell. 

In the case of 15 kHz sub-carrier spacing there are two cyclic-prefix lengths, corresponding to seven and six OFDM 
symbols per slot respectively. 

- Normal cycHc prefix: Tcp = 160xTs (OFDM symbol #0) , Tcp = 144xTs (OFDM symbol #1 to #6) 

- Extended cyclic prefix: Tcp.e = 512xTs (OFDM symbol #0 to OFDM symbol #5) 

where T^ = 1/ (2048 x Af) 

In case of 7.5 kHz sub-carrier spacing, there is only a single cyclic prefix length Tcp-iow = 1024xTs, corresponding to 3 
OFDM symbols per slot. 

In case of FDD, operation with half duplex from UE point of view is supported. 

For operation in unpaired spectrum with generic frame structure, DL/UL switching points are generated by not 
transmitting in certain symbols while idle periods, required by the Node B at UL/DL switching points are created using 
time advance mechanism. For the alternative frame structure, the cyclic prefix length, in case of 15 kHz sub-carrier 
spacing, is 
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- Normal cyclic prefix: Tcp = 224xTs (OFDM symbol #0 to #8) 

- Extended cyclic prefix: Tcp.e = 512xTs (OFDM symbol #0 to #7) 

5. 1 .2 Physical-layer processing 

The downlink physical-layer processing of transport channels consists of the following steps: 

- CRC insertion: 24 bit CRC is the basehne for PDSCH; 

Channel coding: Turbo coding based on QPP inner interleaving with trellis termination; 

- Physical-layer hybrid- ARQ processing; 

- Channel interleaving; 

- Scrambling: transport-channel specific scrambling on DL-SCH, BCH, and PCH. Common MCH scrambling for 
all cells involved in a specific MBSFN transmission; 

- Modulation: QPSK, 16QAM, and 64QAM; 

- Layer mapping and pre-coding; 

- Mapping to assigned resources and antenna ports. 

5.1 .3 Physical downlink control channel 

The downlink control signalling is located in the first n OFDM symbols where n<3 and consists of: 

- Transport format, resource allocation, and hybrid- ARQ information related to DL-SCH, and PCH; 

- Uplink scheduling grant; 

ACK/NAK in response to uplink transmission. 

Transmission of control signalling from these groups is mutually independent, e.g., ACK/NAK can be transmitted to a 
UE regardless of whether the same UE is receiving scheduling information or not. 

Multiple physical downlink control channels are supported and a UE monitors a set of control channels. 

Control channels are formed by aggregation of control channel elements, each control channel element consisting of a 
set of resource elements. Different code rates for the control channels are realized by aggregating different numbers of 
control channel elements. 

QPSK modulation is used for all control channels. 

Each separate control channel has its own set of x-RNTL 

There is an implicit relation between the uplink resources used for dynamically scheduled data transmission, or the DL 
control channel used for assignment, and the downlink ACK/NAK resource used for feedback 

5.1 .4 Downlink Reference signal 

The downlink reference signals consist of known reference symbols inserted in the first and third last OFDM symbol of 
each slot. There is one reference signal transmitted per downlink antenna port. The number of downlink antenna ports 
equals 1, 2, or 4. The two-dimensional reference signal sequence is generated as the symbol-by-symbol product of a 
two-dimensional orthogonal sequence and a two-dimensional pseudo-random sequence. There are 3 different two- 
dimensional orthogonal sequences and 170 different two-dimensional pseudo-random sequences. Each cell identity 
corresponds to a unique combination of one orthogonal sequence and one pseudo-random sequence, thus allowing for 
510 unique cell identities 170 cell identity groups with 3 cell identities in each group). 

Frequency hopping can be applied to the downlink reference signals. The frequency hopping pattern has a period of one 
frame (10 ms). Each frequency hopping pattern corresponds to one cell identity group. 
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The downlink MBSFN reference signals consist of known reference symbols inserted every other sub-carrier in the 3rd, 
7th and 1 1th OFDM symbol of sub-frame in case of 15kHz sub-carrier spacing and extended cyclic prefix 

5.1 .5 Downlink multi-antenna transmission 

Multi-antenna transmission with 2 and 4 transmit antennas is supported. The maximum number of codeword is two 
irrespective to the number of antennas with fixed mapping between code words to layers. 

Spatial division multiplexing (SDM) of multiple modulation symbol streams to a single UE using the same time- 
frequency (-code) resource, also referred to as Single-User MIMO (SU-MIMO) is supported. When a MIMO channel is 
solely assigned to a single UE, it is known as SU-MIMO. Spatial division multiplexing of modulation symbol streams 
to different UEs using the same time-frequency resource, also referred to as MU-MIMO, is also supported. There is 
semi-static switching between SU-MIMO and MU-MIMO per UE. 

In addition, the following techniques are supported: 

- Code-book-based pre-coding with a single pre-coding feedback per full system bandwidth when the system 
bandwidth (or subset of resource blocks) is smaller or equal tol2RB and per 5 adjacent resource blocks or the 
full system bandwidth (or subset of resource blocks) when the system bandwidth is larger than 12RB. 

- Rank adaptation with single rank feedback referring to full system bandwidth. Node B can override rank report. 

5.1 .6 MBSFN transmission 

MBSFN is supported for the MCH transport channel. Multiplexing of transport channels using MBSFN and non- 
MBSFN transmission is done on a per-sub-frame basis. Additional reference symbols, transmitted using MBSFN are 
transmitted within MBSFN subframes. 

5.1 .7 Physical layer procedure 

5.1.7.1 Link adaptation 

Link adaptation (AMC: adaptive modulation and coding) with various modulation schemes and channel coding rates is 
applied to the shared data channel. The same coding and modulation is applied to all groups of resource blocks 
belonging to the same L2 PDU scheduled to one user within one TTI and within a single stream. 

5.1.7.2 Power Control 

Downlink power control can be used. 

5.1.7.3 Cell search 

Cell search is the procedure by which a UE acquires time and frequency synchronization with a cell and detects the Cell 
ID of that cell. E-UTRA cell search supports a scalable overall transmission bandwidth corresponding to 72 sub-carriers 
and upwards. 

E-UTRA cell search is based on following signals transmitted in the downlink: the primary and secondary 
synchronization signals, the downlink reference signals. 

The primary and secondary synchronization signals are transmitted over the centre 72 sub-carriers in the first and sixth 
subframe of each frame. 

Neighbour-cell search is based on the same downlink signals as initial cell search. 

5.1 .8 Physical layer measurements definition 

The physical layer measurements to support mobility are classified as: 
within E-UTRAN (intra-frequency, inter- frequency); 

- between E-UTRAN and GERAN/UTRAN (inter-RAT). 
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For measurements within E-UTRAN at least two basic UE measurement quantities shall be supported: 
Reference symbol received power (RSRP); 
- E-UTRA carrier received signal strength indicator (RSSI). 

5.2 Uplink Transmission Scheme 
5.2.1 Basic transmission scheme 

For both FDD and TDD, the uplink transmission scheme is based on single-carrier FDMA, more specifically DFTS- 
OFDM. 
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Figure 5.2.1 : Transmitter scheme of SC-FDMA 

The uplink sub-carrier spacing Af= 15 kHz. The sub-carriers are grouped into sets of 12 consecutive sub-carriers, 
corresponding to the uplink resource blocks. 12 consecutive sub-carriers during one slot correspond to one uplink 
resource block. In the frequency domain, the number of resource blocks, Nrb, can range from NRB-min = 6 to NRB-max = 
[110]. 

There are two cyclic-prefix lengths defined: Normal cyclic prefix and extended cyclic prefix corresponding to seven 
and six SC-FDMA symbol per slot respectively. 

- Normal cycHc prefix: Tcp = 160xTs (SC-FDMA symbol #0) , Tcp = 144xTs (SC-FDMA symbol #1 to #6) 

- Extended cyclic prefix: Tcp.e = 512xTs (SC-FDMA symbol #0 to SC-FDMA symbol #5) 
Correspondingly, for the alternative frame structure, the cyclic prefix length is listed in table 5.2 

Table 5.2: Cyclic prefix length for alternative frame structure 



/ 


No 

^^BW - 


rmal cv 

^300 


Clio pref 

300 < 

^CP,/ 


ix 


Exte 

^BW - 

^CP,/ 


mded c 

^300 


yclic pre 

300 < 

^CP,/ 


fix 

^BW 





320 


2048 


224 


2048 


560 


2048 


472 


2048 


1 

2 
3 
4 
5 
6 
7 
8 
9 


192 


1024 


204 


1024 


423 


1024 


456 


1024 


2048 


2048 


2048 


2048 


1024 


1024 


1024 


1024 


2048 


2048 


2048 


2048 











5.2.2 Physical-layer processing 



The uplink physical layer processing of transport channels consists of the following steps: 

- CRC insertion: 24 bit CRC is the basehne for PUSCH; 

- Channel coding: turbo coding based on QPP inner interleaving with trellis termination; 

- Physical-layer hybrid- ARQ processing; 
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- Scrambling: UE-specific scrambling; 

- Modulation: QPSK, 16QAM, and 64QAM (optional in UE); 

- Mapping to assigned resources [and antennas]. 

5.2.3 Physical uplink control channel 

The PUCCH shall be mapped to a control channel resource in the uplink. A control channel resource is defined by a 
code and two resource blocks, consecutive in time, with hopping at the slot boundary. 

Depending on presence or absence of uplink timing synchronization, the uplink physical control signalling can differ. 

In the case of time synchronization being present, the outband control signalling consists of: 

- CQI; 

- ACK/NAK; 

- Scheduling request. 

The CQI informs the scheduler about the current channel conditions as seen by the UE. If MIMO transmission is used, 
the CQI includes necessary MIMO-related feedback. 

The HARQ feedback in response to downlink data transmission consists of a single ACK/NAK bit per HARQ process. 

5.2.4 Uplink Reference signal 

uplink reference signals [for channel estimation for coherent demodulation] are transmitted in the 4-th block of the slot 
[assumed normal CP] . The uplink reference signals sequence length equals the size (number of sub-carriers) of the 
assigned resource. 

The uplink reference signals are based on [prime -length] Zadoff-chu sequences that are either truncated or cyclically 
extended to the desired length 

Multiple reference signals can be created: 

- Based on different Zadoff-Chu sequence from the same set of Zadoff-Chu sequences; 

- Different shifts of the same sequence. 

5.2.5 Random access preamble 

The physical layer random access burst consists of a cyclic prefix, a preamble, and a guard time during which nothing is 
transmitted. 

The random access preambles are generated from Zadoff-Chu sequences with zero correlation zone, ZC-ZCZ, 
generated from one or several root Zadoff-Chu sequences. 

5.2.6 Uplink multi-antenna transmission 

The baseline antenna configuration for uphnk MIMO is MU-MIMO. To allow for MU-MIMO reception at the Node B, 
allocation of the same time and frequency resource to several UEs, each of which transmitting on a single antenna, is 
supported. 

Closed loop type adaptive antenna selection transmit diversity shall be supported for FDD (optional in UE). 
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5.2.7 Physical channel procedure 

5.2.7.1 Link adaptation 

Uplink link adaptation is used in order to guarantee the required minimum transmission performance of each UE such 
as the user data rate, packet error rate, and latency, while maximizing the system throughput. 

Three types of link adaptation are performed according to the channel conditions, the UE capability such as the 
maximum transmission power and maximum transmission bandwidth etc., and the required QoS such as the data rate, 
latency, and packet error rate etc. Three link adaptation methods are as follows. 

Adaptive transmission bandwidth; 

- Transmission power control; 

- Adaptive modulation and channel coding rate. 

5.2.7.2 Uplink Power control 

Intra-cell power control: the power spectral density of the uplink transmissions can be influenced by the eNB. 

5.2.7.3 Uplink tinning control 

The timing advance is derived from the UL received timing and sent by the eNB to the UE which the UE uses to 
advance/delay its timings of transmissions to the eNB so as to compensate for propagation delay and thus time align the 
transmissions from different UEs with the receiver window of the eNB. 

The timing advance command is on a per need basis with a granularity in the step size of 0.52 |Lls (16xTs). 



5.3 Transport Channels 



The physical layer offers information transfer services to MAC and higher layers. The physical layer transport services 
are described by how and with what characteristics data are transferred over the radio interface. An adequate term for 
this is "Transport Channel". 

NOTE: This should be clearly separated from the classification of what is transported, which relates to the 
concept of logical channels at MAC sublayer. 

Downlink transport channel types are: 

1. Broadcast Channel (BCH) characterised by: 

- fixed, pre-defined transport format; 

- requirement to be broadcast in the entire coverage area of the cell. 

2. Downlink Shared Channel (DL-SCH) characterised by: 

- support for HARQ; 

- support for dynamic link adaptation by varying the modulation, coding and transmit power; 

- possibility to be broadcast in the entire cell; 

- possibility to use beamforming; 

- support for both dynamic and semi- static resource allocation; 

- support for UE discontinuous reception (DRX) to enable UE power saving; 
support for MB MS transmission (FES). 

NOTE: the possibility to use slow power control depends on the physical layer. 
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3. Paging Channel (PCH) characterised by: 

- support for UE discontinuous reception (DRX) to enable UE power saving (DRX cycle is indicated by the 
network to the UE); 

- requirement to be broadcast in the entire coverage area of the cell; 

- mapped to physical resources which can be used dynamically also for traffic/other control channels. 

4. Multicast Channel (MCH) characterised by: 

- requirement to be broadcast in the entire coverage area of the cell; 
support for SEN combining of MB MS transmission on multiple cells; 

- support for semi-static resource allocation e.g. with a time frame of a long cyclic prefix. 
Uplink transport channel types are: 

1. Uplink Shared Channel (UL-SCH) characterised by: 

- possibility to use beamforming; (likely no impact on specifications) 

- support for dynamic link adaptation by varying the transmit power and potentially modulation and coding; 

- support for HARQ; 

- support for both dynamic and semi-static resource allocation. 

NOTE: the possibility to use uplink synchronisation and timing advance depend on the physical layer. 

2. Random Access Channel(s) (RACH) characterised by: 

limited control information; 

- collision risk; 

NOTE: the possibility to use open loop power control depends on the physical layer solution. 

5.3.1 Mapping between transport channels and physical channels 

The figures below depict the mapping between transport and physical channels (in grey the items for EES): 




Downlink 
Transport Channels 



Downlink 
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Figure 5.3.1-1 : Mapping between downlink transport channels and downlink physical channels 
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Figure 5.3.1-2: Mapping between uplink transport channels and uplink physical channels 



5.4 E-UTRA physical layer model 



The E-UTRA physical-layer model captures those characteristics of the E-UTRA physical-layer that are relevant from 
the point-of-view of higher layers. More specifically, the physical-layer model captures: 

- The structure of higher-layer data being passed down to or up from the physical layer; 

- The means by which higher layers can configure the physical layer; 

- The different indications (error indications, channel-quality indications, etc.) that are provided by the physical 
layer to higher layers; 

- Other (non-transport-channel-based) higher-layer peer-to-peer signalling supported by the physical layer. 

5.4.1 Physical-layer model of E-UTRA transport channels 



5.4.1.1 



Downlink-Shared Channel 



The DL-SCH physical-layer model is described based on the corresponding DL-SCH physical-layer-processing chain, 
see Figure 5.4.1.1. Processing steps that are relevant for the physical-layer model, e.g. in the sense that they are 
configurable by higher layers, are highlighted in blue on the figure. 

- Higher-layer data passed to/from the physical layer 

- N (at least up to two) transport blocks of dynamic size delivered to the physical layer once every TTI. 

- CRC and transport-block-error indication 

- Transport-block-error indication delivered to higher layers. 

- FEC and rate matching 

- Channel coding rate is implicitly given by the combination of transport block size, modulation scheme and 
resource assignment; 

- Physical layer model support of HARQ: in case of Incremental Redundancy, the corresponding Layer 2 
Hybrid- ARQ process controls what redundancy version is to be used for the physical layer transmission for 
each TTI. 

- Interleaving 

- No control of interleaving by higher layers. 

- Data modulation 

- Modulation scheme is decided by MAC Scheduler (QPSK, 16QAM and 64 QAM). 

- Mapping to resource blocks 
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- L2-controlled resource assignment. 

- Physical-layer processing Step 6: Multi-antenna processing 

- MAC Scheduler partly configures mapping from assigned resource blocks (for each stream) to the available 
number of antenna ports. 

- Support for Hybrid-ARQ-related signalling 

The model of Figure 5.4.1.1 also captures: 

- Transport via physical layer of Hybrid- ARQ related information associated with the DL-SCH, to the peer 
HARQ process at the receiver side; 

- Transport via physical layer of corresponding HARQ acknowledgements to DL-SCH transmitter side. 

NOTE: The signalling of transport- format and resource-allocation is not captured in the physical-layer model. At 
the transmitter side, this information can be directly derived from the configuration of the physical layer. 
The physical layer then transports this information over the radio interface to its peer physical layer, 
presumably multiplexed in one way or another with the HARQ-related information. On the receiver side, 
this information is, in contrast to the HARQ-related information, used directly within the physical layer 
for DL-SCH demodulation, decoding etc., without passing through higher layers. 
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Figure 5.4.1.1 : DL-SCH physical-layer model 

When carrying information related to PCCH or BCCH, the L1/L2 control channel may need to be more robust (FFS). 



5.4.1.2 



Broadcast Channel 



The BCH transport channel is characterized by a fixed pre-defined transport format. The TTI (repetition rate) of the 
BCH is FFS. The BCH physical-layer model is described based on the corresponding BCH physical-layer-processing 
chain, see Figure 5.4.1.2: 

- Higher-layer data passed to/from the physical layer 

- A single (fixed-size) transport block per TTI. 

- CRC and transport-block-error indication 

- Transport-block-error indication delivered to higher layers. 
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FEC and rate matching 

Channel coding rate is implicitly given by the combination of transport block size, modulation scheme and 
resource assignment; 

- No BCH Hybrid ARQ, i.e. no higher-layer control of redundancy version. 
Interleaving 

- No control of interleaving by higher layers. 
Data modulation 

Fixed modulation scheme (QPSK), i.e. not higher-layer control. 
Mapping to resource blocks 

Fixed pre-determined transport format and resource allocation, i.e. no higher-layer control. 

Physical-layer processing Step 6: Multi-antenna processing 

Fixed pre-determined processing, i.e. no higher-layer control. 
Support for Hybrid-ARQ-related signalling 

- No Hybrid ARQ. 
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Figure 5.4.1.2: BCH physical-layer model 



It is FFS whether the BCH needs to be extended, in which case the BCH would comprise a primary and a secondary 
BCH. 

NOTE In case the BCH is extended, the characteristics of the primary BCH (P-BCH) would be as defined in the 
above. The P-BCH would carry scheduling information of the secondary BCH (S-BCH). The S-BCH 
would apply a fixed coding while its carrier bandwidth may be limited 



5.4.1.3 



Paging Channel 



The PCH physical-layer model is described based on the corresponding PCH physical-layer-processing chain, see 
Figure 5.4.1.3. Processing steps that are relevant for the physical-layer model, e.g. in the sense that they are 
configurable by higher layers, are highlighted in blue on the figure. 
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Higher-layer data passed to/from the physical layer 

- A single transport block per TTI. 

CRC and transport-block-error indication 

Transport-block-error indication delivered to higher layers. 

FEC and rate matching 

Channel coding rate is implicitly given by the combination of transport block size, modulation scheme and 
resource assignment; 

No PCH Hybrid ARQ, i.e. no higher-layer control of redundancy version. 
Interleaving 

No control of interleaving by higher layers. 
Data modulation 

- Modulation scheme is decided by MAC Scheduler. 
Mapping to resource blocks 

- L2 controlled resource assignment; 

- Possible support of dynamic transport format and resource allocation. 
Physical-layer processing Step 6: Multi-antenna processing 

- MAC Scheduler partly configures mapping from assigned resource blocks to the available number of antenna 
ports. 

Support for Hybrid-ARQ-related signalling 

No Hybrid ARQ. 
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Figure 5.4.1.3: PCH physical-layer model 
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5.4.1.4 



Multicast Channel 



The MCH is characterized by the support for multi-cell reception at the UE (a.k.a. "SFN" transmission). This implies 
that only semi-static configuration of the MCH transport format and resource assignment is possible. The MCH 
physical-layer model is described based on the corresponding PCH physical-layer-processing chain, see Figure 5.4.1.4. 
Processing steps that are relevant for the physical-layer model, e.g. in the sense that they are configurable by higher 
layers, are highlighted in blue. 

- Higher-layer data passed to/from the physical layer 

- N (at least up to 2) transport blocks delivered to physical layer once every TTI. 

- CRC and transport-block-error indication 

Transport-block-error indication delivered to higher layers. 

- FEC and rate matching 

Channel coding rate is implicitly given by the combination of transport block size, modulation scheme and 
resource assignment; 

No MCH Hybrid ARQ, i.e. no higher-layer control of redundancy version. 

- Interleaving 

No control of interleaving by higher layers. 

- Data modulation 

Modulation scheme is decided by MAC Scheduler. 

- Mapping to resource blocks 

- L2 controlled semi-static resource assignment. 

- Physical-layer processing Step 6: Multi-antenna processing 

- MAC Scheduler partly configures mapping from assigned resource blocks (for each stream) to the available 
number of antenna ports. 

- Support for Hybrid-ARQ-related signalling 

- No Hybrid ARQ. 
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Figure 5.4.1.4: MCH physical-layer model 

5.4.1 .5 Uplink Shared Channel 

The UL-SCH physical-layer model is described based on the corresponding PCH physical-layer-processing chain, see 
Figure 5.4.1.5. Processing steps that are relevant for the physical-layer model, e.g. in the sense that they are 
configurable by higher layers, are highlighted in blue. It should be noted that, in case UL-SCH, the scheduling decision 
is at least partly made at the network side. The uplink transmission control in the UE then configures the uplink 
physical-layer processing, based on uplink transport-format and resource-assignment information received on the 
downlink. 

- Higher-layer data passed to/from the physical layer 

N (N may be limited to one) transport blocks of dynamic size delivered to the physical layer once every TTI. 

- CRC and transport-block-error indication 

Transport-block-error indication delivered to higher layers. 

- FEC and rate matching 

- Channel coding rate is implicitly given by the combination of transport block size, modulation scheme and 
resource assignment; 

Physical layer model support of HARQ: in case of Incremental Redundancy, the corresponding Layer 2 
Hybrid- ARQ process controls what redundancy version is to be used for the physical layer transmission for 
each TTI. 

- Interleaving 

- No control of interleaving by higher layers. 

- Data modulation 

- Modulation scheme is decided by MAC Scheduler (at least QPSK and 16QAM). 

- Mapping to resource blocks 

- L2-controlled resource assignment. 

- Physical-layer processing Step 6: Multi-antenna processing 

- MAC Scheduler partly configures mapping from assigned resource blocks (for each stream) to the available 
number of antenna ports. 

- Support for Hybrid-ARQ-related signalling 

The model of Figure 5.4.1.5 also captures 

- Transport via physical layer of Hybrid- ARQ related information (exact info is FFS) associated with the UL- 
SCH, to the peer HARQ process at the receiver side; 

- Transport via physical layer of corresponding HARQ acknowledgements to UL-SCH transmitter side. 
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Figure 5.4.1.5: UL-SCH pliysical-layer model 



5.4.1.6 



Random-access Channel 



5.4.2 Physical-layer indications 

In addition to decoded transport blocks, the physical layer also provides higher layers with different indicators. The 
indicators delivered to higher layers may originate in the corresponding physical layer on in the physical layer of the 
peer entity (transported over the air by means of LI signalling). 



5.4.2.1 



Error indicators 



The error indicators (see Figures 5.4.1.1-5.4.1.5) are one type of indicators. An error indicator indicates whether or not 
the physical layer has correctly decoded a received transport block 



5.4.2.2 



Channel-quality indicators 



Channel-quality indicators (CQI) indicate the downlink and uplink channel quality. The channel-quality indicators are 
delivered by the eNB physical layer to the eNB MAC layer. Exactly how the channel-quality indicators are generated 
within the physical layer is a physical-layer-internal issue and may e.g. depend on the duplex scheme (FDD or TDD). 



Layer 2 



Layer 2 is split into the following sublayers: Medium Access Control (MAC), Radio Link Control (RLC) and Packet 
Data Convergence Protocol (PDCP). 

This subclause gives a high level description of the Layer 2 sub-layers in terms of services and functions. The two 
figures below depict the PDCP/RLC/MAC architecture for downlink and uplink, where: 

- Service Access Points (SAP) for peer-to-peer communication are marked with circles at the interface between 
sublayers. The SAP between the physical layer and the MAC sublayer provides the transport channels. The 
SAPs between the MAC sublayer and the RLC sublayer provide the logical channels. 

- The multiplexing of several logical channels (i.e. radio bearers) on the same transport channel (i.e. transport 
block) is performed by the MAC sublayer; 
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In both uplink and downlink, only one transport block is generated per TTI in the non-MIMO case. 
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Figure 6-1 : Layer 2 Structure for DL 
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Figure 6-2: Layer 2 Structure for UL 

Note: The location of security functions needs to be re-discussed as a result of moving the PDCP from SAE 
Gateway down to the eNB. 



ETSI 



3GPP TS 36.300 version 8.0.0 Release 8 30 ETSI TS 1 36 300 V8.0.0 (2007-03) 

6.1 MAC Sublayer 

This subclause provides an overview on services and functions provided by the MAC sublayer. 

6.1 .1 Services and Functions 

The main services and functions of the MAC sublayer include: 

- Mapping between logical channels and transport channels; 

- Multiplexing/demultiplexing of RLC PDUs belonging to one or different radio bearers into/from transport blocks 
(TB) delivered to/from the physical layer on transport channels; 

Traffic volume measurement reporting; 

- Error correction through HARQ; 

Priority handling between logical channels of one UE; 

Priority handling between UEs by means of dynamic scheduling; 

- Transport format selection; 

- Mapping of Access Classes to Access Service Classes (FES for RACH); 

- Padding. 

NOTE: How the multiplexing relates to the QoS of the multiplexed logical channels is EES. 

6.1.2 Logical Channels 

Different kinds of data transfer services as offered by MAC. Each logical channel type is defined by what type of 
information is transferred. 

A general classification of logical channels is into two groups: 

- Control Channels (for the transfer of control plane information); 

Traffic Channels (for the transfer of user plane information). 

There is one MAC entity per cell. MAC generally consists of several function blocks (transmission scheduling 
functions, per UE functions, MBMS functions, MAC control functions, transport block generation. . .). Transparent 
Mode is only apphed to BCCH and PCCH. 

6.1.2.1 Control Channels 

Control channels are used for transfer of control plane information only. The control channels offered by MAC are: 

- Broadcast Control Channel (BCCH) 

A downlink channel for broadcasting system control information. 

- Paging Control Channel (PCCH) 

A downlink channel that transfers paging information. This channel is used when the network does not know the 
location cell of the UE. 

- Common Control Channel (CCCH) 

Uplink channel for transmitting control information between UEs and network. This channel is used by the UEs 
having no RRC connection with the network. FES if CCCH needed in downlink as well. 

- Multicast Control Channel (MCCH) 
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A point-to-multipoint downlink channel used for transmitting MBMS control information from the network to 
the UE, for one or several MTCHs. This channel is only used by UEs that receive MBMS. 

NOTE: It is FES how MBMS scheduhng is transmitted by either L2/3 signalhng on MCCH or LI signalhng. 

- Dedicated Control Channel (DCCH) 

A point-to-point bi-directional channel that transmits dedicated control information between a UE and the 
network. Used by UEs having an RRC connection. 

6.1.2.2 Traffic Channels 

Traffic channels are used for the transfer of user plane information only. The traffic channels offered by MAC are: 

- Dedicated Traffic Channel (DTCH) 

A Dedicated Traffic Channel (DTCH) is a point-to-point channel, dedicated to one UE, for the transfer of user 
information. A DTCH can exist in both uplink and downlink. 

- Multicast Traffic Channel (MTCH) 

A point-to-multipoint downlink channel for transmitting traffic data from the network to the UE. This channel is 
only used by UEs that receive MBMS. 

6.1 .3 Mapping between logical channels and transport channels 
6.1 .3.1 Mapping in Uplink 

The figure below depicts the mapping between uplink logical channels and uplink transport channels: 

CCCH DCCH DTCH 

^ — . Uplink 

^~^ Logical channels 




^--^ Uplink 

Transport channels 
RACH UL-SCH 

Figure 6.1.3.1: Mapping between uplink logical channels and uplink transport channels 

In Uplink, the following connections between logical channels and transport channels exist: 

- CCCH can be mapped to UL-SCH; 

- DCCH can be mapped to UL- SCH; 

- DTCH can be mapped to UL-SCH. 

6.1 .3.2 Mapping in Downlink 

The figure below depicts the mapping between downlink logical channels and downlink transport channels (in grey the 
items for FFS): 
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Figure 6.1.3.2: Mapping between downlink logical channels and downlink transport channels 

In Downlink, the following connections between logical channels and transport channels exist: 

- BCCH can be mapped to BCH; 

- BCCH can be mapped to DL-SCH; 

- PCCH can be mapped to PCH; 

- CCCH can be mapped to DL-SCH: FFS if CCCH exists; 

- DCCH can be mapped to DL-SCH; 

- DTCH can be mapped to DL-SCH; 

- MTCH can be mapped to DL-SCH: FFS ; 

- MTCH can be mapped to MCH; 

- MCCH can be mapped to DL-SCH: FFS ; 

- MCCH can be mapped to MCH. 



6.2 RLC Sublayer 



This subclause provides an overview on services, functions and PDU structure provided by the RLC sublayer. Note 
that: 

- The reliability of RLC is configurable: some radio bearers may tolerate rare losses (e.g. TCP traffic); 

- Radio Bearers are not characterized by a fixed sized data unit (e.g. a fixed sized RLC PDU). 

6.2.1 Services and Functions 

The main services and functions of the RLC sublayer include: 

- Transfer of upper layer PDUs supporting AM or UM; 

- TM data transfer; 

- Error Correction through ARQ (CRC check provided by the physical layer, in other words no CRC needed at 
RLC level); 

- Segmentation according to the size of the TB : only if an RLC SDU does not fit entirely into the TB then the 
RLC SDU is segmented into variable sized RLC PDUs, which do not include any padding; 

- Re- segmentation of PDUs that need to be retransmitted: if a retransmitted PDU does not fit entirely into the new 
TB used for retransmission then the RLC PDU is re-segmented; 

The number of re-segmentation is not limited; 
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- Concatenation of SDUs for the same radio bearer; 

- In-sequence delivery of upper layer PDUs except at HO in the uplink; 

- Duplicate Detection; 

Protocol error detection and recovery; 

- Flow Control between eNB and UE (FFS); 

- SDU discard; 

- Reset. 

6.2.2 PDU Structure 

Figure 6.2.2 below depicts the RLC PDU structure where: 

- The PDU sequence number carried by the RLC header is independent of the SDU sequence number (i.e. PDCP 
sequence number); 

- A red dotted line indicates the occurrence of segmentation; 

- Because segmentation only occurs when needed and concatenation is done in sequence, the content of an RLC 
PDU can generally be described by the following relations: 

{0; 1 } last segment of SDUi + [0; n] complete SDUs + {0; 1 } first segment of SDUi+n+i ; or 

1 segment of SDUi . 



RLC SDU 



n+1 



n+2 



n+3 



RLC header 
'< RLC PDU- 



Figure 6.2.2: RLC PDU Structure 



6.3 PDCP Sublayer 



This subclause provides an overview on services, functions and PDU structure provided by the PDCP sublayer. 

6.3.1 Services and Functions 

The main services and functions of the PDCP sublayer include: 
Header compression and decompression: ROHC only; 

- Transfer of user data: transmission of user data means that PDCP receives PDCP SDU from the NAS and 
forwards it to the RLC layer and vice versa; 

- Reordering of the downlink RLC SDUs at least during inter-eNB mobility; 

- In-sequence delivery of upper layer PDUs at HO in the uplink (FFS); 
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- Duplicate detection of lower layer SDUs; 

- Ciphering of user plane data and control plane data (NAS Signalling); 

Note: The location of security, reordering and in-sequence delivery functions need to be re-discussed as a result 
of moving the PDCP from SAE Gateway down to the eNB. 

NOTE: When compared to UTRAN, the lossless DL RLC PDU size change is not required. 

6.3.2 PDU Structure 

Figure 6.3.2 below depicts the PDCP PDU structure where: 

- PDCP PDU and PDCP header are octet-aligned; 

- PDCP header can be either 1 or 2 bytes long. 



PDCP header 



PDCP SDU 



-PDCP PDU- 



Figure 6.3.2: PDCP PDU Structure 

6.4 Data flows through Layer 2 
7 RRC 

This subclause provides an overview on services and functions provided by the RRC sublayer. 

7.1 Services and Functions 

The main services and functions of the RRC sublayer include: 

- Broadcast of System Information related to the non-access stratum (NAS); 

- Broadcast of System Information related to the access stratum (AS); 

- Paging; 

Establishment, maintenance and release of an RRC connection between the UE and E-UTRAN including: 

- Allocation of temporary identifiers between UE and E-UTRAN; 

- Configuration of signalling radio bearer(s) for RRC connection: 

- Low priority SRB and high priority SRB. 

- Security functions including: 

- Integrity protection for RRC messages; 

- Ciphering for RRC messages. 

Note: The location of security functions needs to be re-discussed as a result of moving the PDCP from SAE 
Gateway down to the eNB. 

- Establishment, configuration, maintenance and release of point to point Radio Bearers; 
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- Mobility functions including: 

UE measurement reporting and control of the reporting for inter-cell and inter-RAT mobility; 

- Inter-cell handover; 

- UE cell selection and reselection and control of cell selection and reselection; 

- Context transfer between eNB s . 

- Notification for MBMS services (FES); 

Establishment, configuration, maintenance and release of Radio Bearers for MBMS services (EES); 

- QoS management functions; 

- UE measurement reporting and control of the reporting; 

- MBMS control (EES); 

- NAS direct message transfer to/from NAS from/to UE. 

7.2 RRC protocol states & state transitions 

RRC uses the following states: 

- RRCJDLE: 

- UE specific DRX configured by NAS; 

- Broadcast of system information; 

- Paging; 

Cell re-selection mobility; 

- The UE shall have been allocated an id which uniquely identifies the UE in a tracking area; 

- No RRC context stored in the eNB. 

- RRC_CONNECTED: 

- UE has an E-UTRAN-RRC connection; 

- UE has context in E-UTRAN; 

- E-UTRAN knows the cell which the UE belongs to; 
Network can transmit and/or receive data to/from UE; 

- Network controlled mobility (handover); 

- Neighbour cell measurements; 

- At PDCP/RLC/MAC level: 

- UE can transmit and/or receive data to/from network; 

- UE monitors control signalling channel for shared data channel to see if any transmission over the shared 
data channel has been allocated to the UE; 

- UE also reports channel quality information and feedback information to eNB ; 

- DRX/DTX period can be configured according to UE activity level for UE power saving and efficient 
resource utilization. This is under control of the eNB. 
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7.3 Transport of NAS messages 

In E-UTRAN, NAS messages are either concatenated with RRC messages or carried in RRC without concatenation: 

- Concatenated messages: 

- Initial Direct Transfer is concatenated with RRC connection request if the transport block size allows it 
(FFS); 

- Other NAS messages maybe concatenated with RRC messages i.e. for synchronised NAS/RRC 
procedure; 

- Integrity protection of the NAS messages from RRC is FFS as integrity protection is already applied in 
the MME. 

- Non-concatenated messages: 

- No integrity protection from RRC; 



7.4 System Information 



Scheduling information (indicating starting times) is provided for a group of system information blocks (SIBs) that have 
the same scheduling requirements (i.e. periodicity). Such a group of SIBs is referred to as a Scheduling Unit (SU). An 
SU may cover multiple subframes. It is expected that typically 3 or 4 SUs will be used. The mapping of SIBs on to SUs 
may be configurable (FFS). 

NOTE The possibility to schedule segments of an SU into non-contiguous subframes (e.g. for very large SIBs 
without strong delay requirements) is FFS. 

The following system information is carried on the BCH: 

- Physical layer parameters (e.g. bandwidth); 

- System Frame Number (SEN, unless provided otherwise); 

- Scheduling information of the most frequently repeated Scheduling Unit (SU-1); 

- Value tag(s) (FFS). 

The following system information is carried within the most frequently repeated Scheduling Unit (SU-1): 
One or more PLMN identities; 

- Tracking Area Code; 

- Cell identity; 

- Cell barring status; 

Scheduling information of the other Scheduling Units (other than SU-1); 

SIB mapping information i.e. indication in which SU the SIBs is included (FFS). 

SU-1 should include all access restriction related parameters. SU-1 is carried on the DL-SCH, unless the BCH is 
extended. In the latter case, S-BCH may carry (part of) the SU-1 information. 

System information may also be provided to the UE by means of dedicated signalling e.g. upon handover. 
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7.5 RRC Procedures 



8 E-UTRAN identities 

8.1 E-UTRAN related UE identities 

The following E-UTRAN related UE identities are used: 

a) C-RNTI: 

The C-RNTI provides a unique UE identification at the cell level identifying RRC Connection; 

- It is assumed that this identity is used for scheduling unless the cost would turn out to be too high and the 
introduction of a separate MAC identity would be required. 

b) Random value for contention resolution: 

During some transient states, the UE is temporarily identified with a random value for contention resolution 
purposes. 

8.2 Networl^ entity related Identities 

The following identities are used in E-UTRAN for identifying a specific network entity: 

a) MME identity: 

- It is agreed that a UE in LTE_IDLE establishing an RRC connection has to provide a unique identification of 
its current MME to the eNB when the connection establishment is initially related to NAS signalling, in order 
for the eNB to fetch the UE context from the MME; 

It is FES whether this MME identity is also provided when the RRC connection is initially intended for user 
plane traffic; 

- It is FES whether this MME identity is provided by the UE to the eNB as a separate identity, or whether this 
MME identity is included in the TMSI for MME. 

b) eNB identity or cell identity (FES): 

The signalling sequence to be followed in case a UE in LTE_ACTIVE accesses a cell in which no UE 
context has been established yet (kind of "cell update") is currently not agreed. Identified options are: 

1) In order to obtain the UE context/data from the old eNB, the new eNB directly contacts the old eNB 
without consulting the MME; 

2) In order to obtain the UE context/data from the old eNB, the new eNB consults the MME to obtain the 
identity of the old eNB; 

3) In order to obtain a UE context, the new eNB contacts the MME. 

- If it is required for the new eNB to be able to contact the old eNB without involving the MME (case 1 
above), the UE has to provide a network entity related identification that enables the new eNB to contact the 
old eNB, and that enables the old eNB to uniquely identify the UE for retrieving the correct UE context. For 
this purpose either an eNB identity or cell identity could be used. 

c) Tracking Area identity (FFS): 

Unique identification of a Tracking Area in a PLMN. 
The following identities are broadcast in every E-UTRAN cell: 
a) Cell identity: 
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- Uniquely identifying the cell in the area (size of area is FFS). 

b) One or more Tracking Area identities (FFS): 

- Tracking Area (s) this cell belongs to. 

c) One or more PLMNs: 

- PLMN (s) for which this cell is providing radio access. 



ARQ and HARQ 



E-UTRAN provides ARQ and HARQ functionalities. The ARQ functionality provides error correction by 
retransmissions in acknowledged mode at Layer 2. The HARQ functionality ensures delivery between peer entities at 
Layer 1. 



9.1 HARQ principles 



The HARQ within the MAC sublayer has the following characteristics: 

- N-process Stop-And-Wait HARQ is used; 

- The HARQ is based on ACK/NACKs; 

- In the downlink: 

- Asynchronous retransmissions with adaptive transmission parameters are supported; 

- Additional optimisations (e.g. less adaptive/synchronous) are FFS. 

- In the uplink: 

HARQ is based on synchronous retransmissions; 

- Whether resource allocation and modulation and coding scheme can be adapted for retransmissions is FFS. 
The HARQ transmits and retransmits TBs; 



9.2 ARQ principles 



The ARQ within the RLC sublayer has the following characteristics: 

- ARQ retransmits RLC PDUs or RLC PDU segments; 

- ARQ retransmissions are based on: 

- RLC status reports; 

- HARQ/ ARQ interactions (see subclause 9.3). 

- Polling for RLC status report is used when needed by RLC; 

- Status reports can be triggered by upper layers; 

- Means to discard a SDU not yet transmitted or under transmission should be supported; 

- Means to reset and/or re-establish RLC should be supported. 



9.3 



HARQ/ARQ interactions 



In HARQ assisted ARQ operation, ARQ uses knowledge obtained from the HARQ about the transmission/reception 
status of aTB e.g.: 
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- If the HARQ transmitter detects a failed delivery of a TB due to e.g. maximum retransmission limit is reached 
the relevant transmitting ARQ entities are notified and potential retransmissions and re- segmentation can be 
initiated; 

If the HARQ receiver is able to detect a NACK to ACK error it is FFS if the relevant transmitting ARQ entities 
are notified via explicit signalling; 

- If the HARQ receiver is able to detect TB transmission failure it is FFS if the receiving ARQ entities are 
notified. 



10 Mobility 

E-UTRAN mobility in LTE_IDLE and LTE_ACTIVE should provide means for load balancing. 

10.1 Intra E-UTRAN 

In E-UTRAN RRC_CONNECTED state, network-controlled UE-assisted handovers are performed and various 
DRX/DTX cycles are supported: 

- UE performs neighbour cell measurements based on measurement control and neighbour cell information from 
the network: 

- List of carrier frequencies of inter- frequency neighbours is signalled to the UE (other information FFS); 

- Network signals reporting criteria for event-triggered and periodical reporting. 
Following defines the handover support within E-UTRAN: 

- The intra E-UTRAN HO in RRC_CONNECTED state is UE assisted NW controlled HO with HO preparation 
signalhng in E-UTRAN: 

- Part of the HO command comes from the target eNB and is transparently forwarded to the UE by the source 
eNB; 

- The QoS profiles in use by the UE (SAE bearer attributes) are sent to the target eNB by the source eNB, and 
it is FFS if also the currently used AS configuration is sent (intra-MME case); 

- Both the source ENB and UE keep some context (e.g. C-RNTI) to enable the return of the UE in case of HO 
failure; 

- UE accesses the target cell via contention-based RACH (the use of dedicated resources for accessing the 
target cell in a contention-free manner is FFS). 

- In E-UTRAN RRC_IDLE state, cell reselections are performed and DRX is supported. 

10.1.1 Mobility Management in LTEJDLE 
10.1.1.1 Cell selection 

The principles of PLMN selection in E-UTRA are based on the 3 GPP PLMN selection principles. Cell selection is 
required on transition from LTE_DET ACHED to LTEJDLE or LTE_ACTIVE. 

Cell selection: 

- The UE NAS identifies a selected PLMN and equivalent PLMNs; 

The UE searches the E-UTRA frequency bands and for each carrier frequency identifies the strongest cell. It 
reads cell system information broadcast to identify its PLMN(s): 

- Details for the cell search are FFS; 
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- The UE may search each carrier in turn ("initial cell selection") or make use of stored information to shorten 
the search ("stored information cell selection"). 

- The UE seeks to identify a suitable cell; if it is not able to identify a suitable cell it seeks to identify an 
acceptable cell. When a suitable cell is found or if only an acceptable cell is found it camps on that cell and 
commence the cell reselection procedure: 

- A suitable cell is one for which the measured cell attributes satisfy the cell selection criteria; the cell PLMN 
is the selected PLMN, registered or an equivalent PLMN; the cell is not barred or reserved and the cell is not 
part of a tracking area which is in the list of "forbidden tracking areas for roaming"; 

Note: the above text will be revised if it is agreed that a cell can be a member of more than one tracking area. 

- An acceptable cell is one for which the measured cell attributes satisfy the cell selection criteria and the cell 
is not barred; 

- The measurements made and the cell selection criteria to be applied are FES. 

Transition to RRCJDLE: 

On transition from RRC_CONNECTED to RRCJDLE, a UE should camp on the last cell for which it was in 
RRC_CONNECTED or a cell/any cell of set of cells or frequency be assigned by RRC in the state transition 
message. 

Recovery from out of coverage: 

The UE should attempt to find a suitable cell in the manner described for stored information or initial cell 
selection above. If no suitable cell is found on any frequency or RAT the UE should attempt to find an 
acceptable cell. 

10.1.1.2 Cell reselection 

UE in RRC_IDLE performs cell reselection. The principles of the procedure are the following: 

- Cell reselection takes place in a hierarchical or non hierarchical cell topology. The type of topology will be 
indicated in system information; 

- The UE makes measurements of attributes of the serving and neighbour cells to enable the reselection process: 

- Cells listed in the serving cell system information broadcast are searched and measured by the UE; it is FES 
whether the UE can search and measure cells that are not listed in system information; 

- The attributes to be measured for E-UTRAN cells are EES; 

Measurements may be omitted if the serving cell attribute fulfils particular search or measurement criteria. The 
criteria and rules relating to which measurements may be omitted are EES; 

Cell reselection identifies the cell that the UE should camp on. It is based on cell reselection criteria which 
involves measurements of the serving and neighbour cells. Details for cell reselection criteria are EES (e.g. 
whether a cell specific offset is applied to measurements); 

- Cell reselection parameters are applicable for all UEs in a cell, but it is possible to configure specific reselection 
parameters per UE group or per UE. 

Cell access restrictions apply as for UTRAN, which consist of access class (AC) barring and cell reservation (e.g. for 
cells "reserved for operator use") applicable for mobiles in RRC_IDLE mode. 
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10.1.1.3 Handling in eNB 

10.1.1.4 Handling above eNB 

1 0.1 .1 .5 Mobility Management Entity (MME) 
10.1.2 Mobility Management in LTE_ACTIVE 

The Intra-E-UTRAN- Access Mobility Support for UEs in LTE_ACTIVE handles all necessary steps already known 
from state of the art relocation/handover procedures, like processes that precedes the final HO decision on the source 
network side (control and evaluation of UE and eNB measurements taking into account certain UE specific area 
restrictions), preparation of resources on the target network side, commanding the UE to the new radio resources and 
finally releasing resources on the (old) source network side. It contains mechanisms to transfer context data between 
evolved nodes, and to update node relations on C-plane and U-plane. 

10.1.2.1 Handover 

The intra E-UTRAN HO in RRC_CONNECTED state is UE assisted NW controlled HO, with HO preparation 
signalhng in E-UTRAN. 

10.1.2.1.1 C-plane handling 

The HO procedure is performed without EPC involvement, i.e. preparation messages are directly exchanged between 
the eNBs. The release of the resources at the source side during the HO completion phase is triggered by the eNB. The 
figure below depicts the basic handover scenario where neither MME nor SAE Gateway changes: 
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Figure 10.1.2.1: Intra-MME/SAE Gateway HO 

Below is a more detailed description of the intra-MME/SAE Gateway HO procedure: 

The UE context within the source eNB contains information regarding roaming restrictions which where 
provided either at connection establishment or at the last TA update. 

1 The source eNB configures the UE measurement procedures according to the area restriction information. 
Measurements provided by the source eNB may assist the function controlling the UE's connection mobility. 

2 UE is triggered to send MEASUREMENT REPORT by the rules set by i.e. system information, specification 
etc. 

3 Source eNB makes decision based on MEASUREMENT REPORT and RRM information to hand off UE. 
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4 The source eNB issues a HANDOVER REQUEST message to the target eNB passing necessary information to 
prepare the HO at the target side (UE X2 signalhng context reference at source eNB, UE SI EPC signalling 
context reference, target cell ID, RRC context, SAE bearer context). UE X2 / UE SI signalling references enable 
the target eNB to address the source eNB and the EPC. The SAE bearer context includes necessary RNL and 
TNL addressing information. QoS profiles of the SAE bearers and possibly the AS configurations of these 
bearers are FES. 

5 Admission Control may be performed by the target eNB dependent on the received SAE bearer QoS information 
to increase the likelihood of a successful HO, if the resources can be granted by target eNB. The target eNB 
configures the required resources according to the received SAE bearer QoS information and reserves a C-RNTI. 

6 Target eNB prepares HO with L1/L2 and sends the HANDOVER REQUEST ACKNOWLEDGE to the source 
eNB. The HANDOVER REQUEST ACKNOWLEDGE message includes a transparent container to be sent to 
the UE as part of the Handover Command. The container may include new C-RNTI, possibly some other 
parameters i.e. access parameters, SIBs, etc. The HANDOVER REQUEST ACKNOWLEDGE message may 
also include RNL/TNL information for the forwarding tunnels, if necessary. 

Steps 7 to 13 provide means to avoid data loss during HO and are further detailed in 10.1.2.1.2 and 10.1.2.3. 

7 The source eNB generates the HANDOVER COMMAND (RRC message) towards the UE. The HANDOVER 
COMMAND includes the transparent container, which has been received from the target eNB. The source 
eNodeB performs the necessary integrity protection and ciphering of the message. The UE receives the 
HANDOVER COMMAND with necessary parameters (i.e. new C-RNTI, possible starting time, target eNB 
SIBs etc) and is commanded by the source eNB to perform the HO. It is probable that UE needs to acknowledge 
reception of the HANDOVER COMMAND with RLC acknowledgment procedure. 

8 After expiry of starting time in HANDOVER COMMAND, UE performs synchronisation to target eNB and then 
starts acquiring UL timing advance. 

9 Network responds with UL allocation and timing advance. 

10 When the UE has successfully accessed the target cell, the UE sends the HANDOVER CONFIRM message (C- 
RNTI) to the target eNB to indicate that the handover procedure is completed for the UE. The target eNB 
verifies the C-RNTI sent in the HANDOVER CONFIRM message. 

1 1 The EPC is informed that the UE has changed cell. The UPE switches the downlink data path to the target side 
and can release any U-plane/TNL resources towards the source eNB. 

12 The EPC confirms the HANDOVER COMPLETE message with the HANDOVER COMPLETE ACK message. 

13 By sending RELEASE RESOURCE the target eNB informs success of HO to source eNB and triggers the 
release of resources. The timing for the target eNB to send this message between steps 10 and 12 is FES. 

14 Upon reception of the RELEASE RESOURCE message, the source eNB can release radio and C-plane related 
resources associated to the UE context. 

NOTE: Details on updating of roaming/area restriction information within E-UTRAN in the course of the HO 
procedure are FES 

10.1.2.1.2 U-plane handling 

The U-plane handling during the Intra-E-UTRAN-Access mobility activity for UEs in LTE_ACTIVE takes the 
following principles into account to avoid data loss during HO and hence to support seamless/lossless service provision: 

- During HO preparation a U-plane tunnel is established between the source eNB and the target eNB. 

During HO execution, user data may be forwarded from the source eNB to the target eNB. The forwarding may 
take place in a service dependent and implementation specific way. 

- Forwarding of user data from the source to the target eNB should take place as long as packets are received at 
the source eNB from the EPC or the source eNB buffer has not been emptied (an implementation dependent 
mechanism decides that data forwarding can be stopped). 

- During HO completion: 
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- The EPC is informed by the target eNB that the UE has gained access at the target eNB by the HANDOVER 
COMPLETE message and the U-plane path is switched by the EPC from the source eNB to the target eNB. 

- The source eNB should continue forwarding of U-plane data as long as packets are received at the source 
eNB from the EPC or the source eNB buffer has not been emptied (an implementation dependent mechanism 
decides that data forwarding can be stopped). 

Note: Details on user plane handling are still FES. The text above reflects the latest status of the Study Item as 
given in TR 25.912. 

10.1.2.2 Path Switch 

10.1.2.3 Data forwarding 

Upon handover, the source eNB forwards all downlink RLC SDUs that have not been acknowledged by the UE to the 
target eNB. The decision of which SDUs to forward can be based for example on RLC status reports or HARQ 
feedback information depending on eNB implementation. The source eNB discards any remaining downlink RLC 
PDUs. The target eNB re-transmits and prioritize all downlink RLC SDUs forwarded by the source eNB as soon as it 
obtains them. Correspondingly, the source eNB does not forward the downlink RLC context to the target eNB. 

Re-ordering of downlink RLC SDUs during handover is provided by the re-ordering function at the UE PDCP layer and 
can be activated at least during inter-eNB mobility. 

Upon handover, the source eNB forwards all successfully received uplink RLC SDUs to the UPE and discards any 
remaining uplink RLC PDUs. The UE re-transmits the uplink RLC SDUs that have not been successfully received by 
the source eNB. Correspondingly, the source eNB neither forwards uplink RLC SDUs nor the uplink RLC context to 
the target eNB. If needed, the PDCP may support re-ordering of uplink RLC SDUs during handover (operator control). 

Note: This needs to be re-discussed as a result of moving the PDCP from UPE down to the eNB. 

10.1.2.4 Handling in eNB 

10.1.2.5 Handling above eNB 

10.1.2.6 Mobility Management Entity (MME) 

1 0.1 .2.7 Tinning Advance 

In RRC_CONNECTED, it remains FES whether the timing advance is permanently maintained or not. If not, MAC 
knows if the LI is synchronised and which procedure to use to start transmitting in the uplink (EES for RRC). 

Cases where the UL synchronisation status may move from "synchronised" to "non-synchronised" include: 

- Expiration of a timer; 

- Non- synchronised handover; 

- Exphcit request by MAC or RRC in the eNB; 

10.1.3 Measurements 

Measurements to be performed by a UE for intra/inter-frequency mobility can be controlled by E-UTRAN, using 
broadcast or dedicated control. In RRC_IDLE state, a UE shall follow the measurement parameters defined for cell 
reselection specified by the E-UTRAN broadcast (as in UTRAN SIB). The use of dedicated measurement control for 
RRCJDLE state is PES. In RRC_CONNECTED state, a UE shall follow the measurement configurations specified by 
RRC directed from the E-UTRAN (e.g. as in UTRAN MEASUREMENT_CONTROL). 

Depending on whether the UE needs transmission/reception gaps to perform the relevant measurements, measurements 
are classified as gap assisted or non gap assisted. A non gap assisted measurement is a measurement on a cell that does 
not require transmission/reception gaps to allow the measurement to be performed. A gap assisted measurement is a 
measurement on a cell that does require transmission/reception gaps to allow the measurement to be performed. 
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Whether a measurement is non gap assisted or gap assisted depends on the UE's capability and current operating 
frequency. The UE determines whether a particular cell measurement needs to be performed in a transmission/reception 
gap and the scheduler needs to know whether gaps are needed. The exact scenarios that require gap assisted 
measurements are FFS (see subclause 9.1.1). 

Measurement gaps are provided and controlled by the network. 

1 0.1 .3.1 Neighbour cell measurements within the serving frequency layer 

In a system with frequency reuse = 1, mobility within the same frequency layer (i.e. between cells with the same carrier 
frequency) is predominant. Good neighbour cell measurements are needed for cells that have the same carrier frequency 
as the serving cell in order to ensure good mobility support and easy network deployment. Search for neighbour cells 
with the same carrier frequency as the serving cell, and measurements of the relevant quantities for identified cells are 
needed. 

NOTE: To avoid UE activity outside the DRX/DTX cycle, the reporting criteria for neighbour cell measurements 
should match the used DRX/DTX cycle. 

1 0.1 .3.2 Neighbour cell measurements of other frequency layers 

Regarding mobility between different frequency layers (i.e. between cells with a different carrier frequency), UE may 
need to perform neighbour cell measurements during DL/UL idle periods that are provided by DRX/DTX or packet 
scheduling (i.e. gap assisted measurements). 

NOTE: How the gaps are controlled, as well as how the scheduler knows the gaps required by the UE, is FFS. 

10.1.4 Paging and C-plane establishment 

Paging groups (where multiple UEs can be addressed) are used on L1/L2 signalling channel: 

- Precise UE identity is found on PCH; 

- DRX is UE specific. 

10.1.5 Random Access Procedure 

The random access procedure is characterized by: 
Common procedure for FDD and TDD; 

- One procedure irrespective of cell size; 

Early contention resolution shall be used i.e. eNB does not wait for NAS reply before resolving contention. 
The random access procedure is outlined on Figure 10.1.5-1 below: 
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UE 



eNB 



-Random Access Preamble > 



< Random Access Response- 



-Scheduled Transmission ► 



4 Contention Resolution- 



Figure 10.1.5-1: Random Access Procedure 

The four steps of the random access procedures are: 

1) Random Access Preamble on RACH in uphnk: 

- 6 bits to carry: a random ID, and possibly (FFS) 1 bit of other information: 

- Cause or size, potentially with priority; 

- Pathloss or CQI to allocate UL resource appropriately. 
NOTE: the total number of bits is 5 for alternative TDD. 

2) Random Access Response on DL-SCH: 

Semi-synchronous (within a flexible window of which the size is one or more TTI) with message 1 ; 

- No HARQ; 

- Addressed to RA-RNTI on L1/L2 control channel; 

Conveys at least RA-preamble identifier. Timing Alignment information, initial UL grant and assignment of 
Temporary C-RNTI (which may or may not be made permanent upon RRC Contention Resolution); 

- Intended for one or multiple UEs in one DL-SCH message. 

3) First scheduled UL transmission on UL-SCH: 

- Uses HARQ; 

- RLC TM: no segmentation; 

- Conveys at least UE identifier (C-RNTI if available); 

- In case of initial access and if the size of the message allows it, the initial NAS message (or something 
allowing to build the initial NAS message in eNB) can be included; 

- Size of the message is dynamic. 

4) Contention Resolution on DL-SCH: 

- Not synchronised with message 3; 

- Content of the message is FFS ; 

- HARQ is supported; 
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- Addressed to the Temporary C-RNTI on L1/L2 control channel (at least for initial access): 

- For UE in RRC_CONNECTED, the use of C-RNTI, HARQ and the consequences thereof (e.g. delay 
impact on other UEs in conjunction with HARQ) are FES; 

- HARQ feedback is transmitted only by the UE which detects its own UE identity, as provided in message 3, 
echoed in the RRC Contention Resolution message. 

At initial access, the four steps are: 

1) Random Access Preamble on RACH; 

2) Random Access Response generated by the MAC sublayer and transmitted on DL-SCH; 

3) RRC Connection Request generated by the RRC layer and transmitted via CCCH on UL-SCH; 

4) RRC Contention Resolution generated by the RRC layer and transmitted via CCCH or DCCH (EES) on DL- 
SCH. 

The Temporary C-RNTI is promoted to C-RNTI for a UE which detects RA success and does not already have a C- 
RNTI; it is dropped by others. A UE which detects RA success and already has a C-RNTI, resumes using its C-RNTI. 

Random access procedure for initial access described above is modelled in Figure 10.1.5-2 below from LI and L2/3 
interaction point of view. L2/L3 receives indication from LI whether ACK is received or DTX is detected after 
indication of Random Access Preamble transmission to LI. L2/3 indicates LI to transmit first scheduled UL 
transmission (RRC Connection Request in case of initial access) or Random Access Preamble based on the indication 
from LI. 



L2/ L3 indicates " Random 
Access Preamble" 
transmission 



L1 transmits " Random 
Access Preamble" 



L2/ L3 procedure 



L1 procedure 




ACK (" Random 
Access Response" 
reception) 



L2/ L3 receives 
indication from L1 



DTX reception (No 
" Random Access 
Response" reception) 



L2/ L3 receives 
indication from L1 



L2/ L3 indicates " RRC 
Connection Request" 
transmission 



L2/ L3 indicates 
" Random Access 
Preamble" transmission 



Figure 10.1.5-2: Interaction model between LI and L2/3 for Random Access Procedure 

10.1.6 Radio Link Failure 

Two phases governs the behaviour associated to radio link failure as shown on Figure 10.1.6: 

- First phase: 

- started upon radio problem detection; 

- leads to radio link failure detection; 

- no UE-based mobility; 

- based on timer or other (e.g. counting) criteria (Ti). 

- Second Phase: 

- started upon radio link failure detection; 

- leads to RRCJDLE; 

- UE-based mobility; 

- Timer based (T2). 
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First Phase 



normal operation 



radio 
problem 
detection 



no recovery during Ti 



Second Phase 



no recovery during T2 



RRC_CONNECTED 



goes back to idle 



RRCJDLE 



radio link failure 
Figure 10.1.6: Radio Link Failure 

Table 10.1.6 below describes how mobility is handled with respect to radio link failure: 

Table 10.1.6: Mobility and Radio Link Failure 



Cases 


First Phase 


Second Phase 


T2 expired 


UE returns to the same cell 


Continue as if no radio 
problems occurred 


Activity cannot be resumed 
without interaction between UE 
and eNB 

Procedure to be used is FFS 
Normally not via RRCJDLE 


Go via RRCJDLE 


UE selects a different cell 
from the same eNB 


N/A 


FFS 


Go via RRCJDLE 


UE selects a cell of a 
different eNB 


N/A 


Go via RRCJDLE 


Go via RRCJDLE 



10.1.7 Radio Access Network Sharing 



E-UTRAN shall support radio access network sharing based on support for multi-to-multi relationship between E- 
UTRAN nodes and EPC nodes (Sl-flex). 

If the E-UTRAN is shared by multiple operators, the system information broadcasted in each shared cell contains the 
PLMN-id of each operator (up to 6) and a single tracking area code (TAC) valid within all the PLMNs sharing the radio 
access network resources. 

The UE shall be able to read up to 6 PLMN-ids, to select one of the PLMN-ids at initial attachment and to indicate this 
PLMN-id to the E-UTRAN in subsequent instances of the Random Access procedures (e.g. as defined in subclause 
10.1.5). The E-UTRAN shall select an appropriate MME for the PLMN indicated by the UE. Once attached to an 
MME, the UE shall be able to indicate the allocated MME in subsequent instances of the Random Access procedures. 
Whether the indication of the selected PLMN or the allocated MME is contained in the temporary UE identity or 
signalled separately is FFS. 

Handling of area restrictions for UE in LTE_ACTIVE shall follow the principles specified in sub-clause 10.4. 



10.1 .8 Handling of Roaming and Area Restrictions for UEs in LTE_ACTIVE 

Handling of roaming/area restrictions and handling of subscription specific preferences in LTE_ACTIVE is performed 
in the eNB based on information provided by the EPC over the SI interface. 

10.2 Inter RAT 

For inter RAT mobility, a list of carrier frequencies of inter-RAT neighbours is signalled to the UE (other information 
FFS). 
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10.2.1 Cell reselection 

10.2.2 Handover 

Inter RAT HO is designed so that changes to GERAN and UTRAN are minimised. This can be done by following the 
principles specified for GERAN to/from UTRAN intersystem HO. In particular the following principles are applied to 
E-UTRAN Inter RAT HO design: 

1 . Inter RAT HO is network controlled through source access system. The source access system decides about 
starting the preparation and provides the necessary information to the target system in the format required by the 
target system. That is, the source system adapts to the target system. The actual handover execution is decided in 
the source system. 

2. Inter RAT HO is backwards handover, i.e. radio resources are prepared in the target 3GPP access system before 
the UE is commanded by the source 3GPP access system to change to the target 3GPP access system. 

3. To enable backwards handover, and while RAN level interfaces are not available, a control interface exists in 
CN level. In Inter RAT HO involving E-UTRAN access, this interface is between 2G/3G SGSN and 
corresponding MME/SAE GW. 

4. The target access system will be responsible for giving exact guidance for the UE on how to make the radio 
access there (this includes radio resource configuration, target cell system information etc.). This information is 
given during the handover preparation and should be transported completely transparently through the source 
access system to the UE. 

5. Mechanisms for avoiding or mitigating the loss of user data (e.g. forwarding or bi-casting) may be used until the 
3 GPP Anchor determines that it can send DL U-plane data directly to the target system. 

6. The handover procedure should not require any UE to CN signalling in order for data to start to flow in the target 
system. This requires that the security context, UE capability context and QoS context is transferred (or 
translated) within the network between source and target system. 

7. Similar handover procedure should apply for handovers of both real time and non-real time services. 

1 0.2.3 Measurements 

1 0.2.3.1 Inter-RAT handovers from E-UTRAN 

Measurements to be performed by a UE for inter-RAT mobility can be controlled by E-UTRAN, using broadcast or 
dedicated control. In RRC_CONNECTED state, a UE shall follow the measurement parameters specified by RRC or 
MAC commands (FES) directed from the E-UTRAN (e.g. as in UTRAN MEASUREMENT_CONTROL). 

UE performs inter-RAT neighbour cell measurements during DL/UL idle periods that are provided by the network 
through suitable DRX/DTX period or packet scheduling if necessary. 

NOTE: How the gaps are controlled, as well as how the scheduler knows the gaps required by the UE, is FES. 

1 0.2.3.2 Inter-RAT handovers to E-UTRAN 

From UTRAN, UE performs E-UTRAN measurements by using idle periods created by compressed mode 
(CELL_DCH), EACH measurement occasions (CELL_FACH - FFS), or DRX (other states). 

From GERAN, E-UTRAN measurements are performed in the same way as WCDMA measurements for handover to 
UTRAN: E-UTRAN measurements are performed in GSM idle frames in a time multiplexed manner. However, it 
should be discussed with GERAN how to ensure that inter-RAT measurements do not take too much measurement 
time, while the requested 3 GPP inter-RAT measurements can be performed well enough. 

Design constraints of 3GPP inter-RAT measurements should be considered when LI details of E-UTRAN concept are 
defined. 
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1 0.2.3.3 Inter-RAT cell reselection from E-UTRAN 

In RRC_IDLE state, a UE shall follow the measurement parameters specified by the E-UTRAN broadcast (as in 
UTRAN SIB). The use of dedicated measurement control is FES. 

10.2.3.4 Limiting measurement load at UE 

Introduction of E-UTRA implies co-existence of various UE capabilities. Each UE may support different combinations 
of RATs, e.g., E-UTRA, UTRA, GSM, and non-3GPP RATs, and different combinations of frequency bands, e.g., 800 
MHz, 1.7 GHz, 2 GHZ, etc. Moreover, some UEs may support the full E-UTRA spectrum bandwidth of 20 MHz, 
whereas some UEs may support only a part of 20 MHz. Despite such heterogeneous environment, the measurement 
load at UE should be minimised. To limit the measurement load and the associated control load: 

E-UTRAN can configure the RATs to be measured by UE; 

- The number of measurement criteria (event and periodic reporting criteria) should be limited (as in TS 25.133 
subclause 8.3.2 [7]); 

E-UTRAN should be aware of the UE capabilities for efficient measurement control, to prevent unnecessary 
waking up of the measurement entity; 

- The UE capabilities should be categorised to prevent diversion of capabilities and conformance test scenarios, 
FES; 

- Support for blind HO (i.e., HO without measurement reports from UE) is FES. 

1 0.2.4 Network Aspects 

1 0.3 Inter 3GPP access system mobility 

10.3.1 Cell reselection 

10.3.2 Handover 

10.3.3 Measurements 

1 0.4 Area Restrictions 

Information on which area restrictions to be applied during LTE_ACTIVE state is provided by the MME at context 
setup over the SI interface. 

The eNB shall store the UE restriction information and use it to determine whether the UE has access to radio resources 
in the E-UTRAN. The source eNB should apply restriction handling when selecting a target eNB. 

The available UE restriction information shall be propagated by the source eNB over X2 at intra E-UTRAN handover. 

1 1 Scheduling and Rate Control 

In order to utilise the SCH resources efficiently, a scheduling function is used in MAC. In this subclause, an overview 
of the scheduler is given in terms of scheduler operation, signalling of scheduler decisions, and measurements to 
support scheduler operation. 
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11.1 Basic Scheduler Operation 



MAC in eNB includes dynamic resource schedulers that allocate physical layer resources for the DL-SCH and UL-SCH 
transport channels. Different schedulers operate for the DL-SCH and UL-SCH. 

The scheduler should take account of the traffic volume and the QoS requirements of each UE and associated radio 
bearers, when sharing resources between UEs. Only "per UE" grants are used to grant the right to transmit on the UL- 
SCH (i.e. there are no "per UE per RB" grants). 

Schedulers may assign resources taking account the radio conditions at the UE identified through measurements made 
at the eNB and/or reported by the UE. 

Radio resource allocations can be valid for one or multiple TTIs. 

Resource assignment consists of physical resource blocks (PRB) and MCS. Allocations for time periods longer than one 
TTI might also require additional information (allocation time, allocation repetition factor. . .). 

Four possible types of allocation are defined: 

- Short lived dynamic allocation: both PRB(s) and allowed MCS are allocated to a given UE for a defined number 
of TTIs; 

NOTE: a UE may "operate" only during certain time periods of the radio frame (indicated from RRC). 

- Short lived fixed allocation: PRB(s) are allocated to a given UE for a defined number of TTIs, and the allowed 
MCS is allocated for an undefined duration; 

NOTE: a UE may "operate" only during certain time periods of the radio frame (indicated from RRC). 

- Long lived dynamic allocation: PRB(s) are allocated to a given UE for an undefined duration, and the MCS is 
dynamically controlled by the network; 

- Long lived fixed allocation: both PRB(s) and allowed MCS are allocated to a given UE for an undefined 
duration. 

This is summarized on the figure below: 



MCS 
Allocation 



Long-lived 
Dynamic 

Allocation 



Long-lived 
Fixed 

Allocation 
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Short-lived 
Dynamic 
Allocation 



Short-lived 

Fixed 
Allocation 



Short-lived 
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Figure 11.1: Allocation Types 

For one UE, the allocation type may be different in UL and DL. Also there may be multiple simultaneous allocation 
types for the same UE. 

Allocations are done one a per UE basis (i.e. not on a per radio bearer basis), but radio bearer restriction may apply for 
certain allocation type e.g. for long live allocation. 
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In both uplink and downlink, E-UTRAN can dynamically allocate resources (PRBs and MCS) to UEs at each TTI via 
the C-RNTI (i.e. short lived dynamic allocation for one TTI). In uplink, when the UE does not have enough data to fill 
the allocated resource, padding is used. 

1 1 .2 Signalling of Scheduler Decisions 

UEs identify whether resources are assigned to them by receiving a L1/L2 control channel. There may be separate 
L1/L2 control channels for uplink and downlink resource assignment. 

Scheduling decisions are signalled via MAC messages or L1/L2 control channel. It is FES whether resources can be 
assigned by other means e.g. MAC headers or RRC signalling. 

1 1 .3 Measurements to Support Scheduler Operation 

Measurement reports are required to enable the scheduler to operate in both uplink and downlink. These include 
transport volume and measurements of a UEs radio environment. The time and frequency granularity of the UE radio 
environment measurement reports is EES. 

Uplink buffer status reports are needed to provide support for QoS-aware packet scheduling. Uplink buffer status 
reports refer to the data that is buffered in the logical channel queues in the UE MAC. The uplink packet scheduler in 
the eNB is located at MAC level. Uplink buffer status reports may be transmitted using MAC signalling (e.g. as a 
specific type of MAC control PDU). A way to separately signal buffer status reports for different QoS classes may be 
used. To define the exact content of buffer status reports and the possible use of physical layer signalling are FES. 

The buffer reporting scheme used in uplink should be flexible in order to support different types of data services. The 
buffer reporting criteria are setup and reconfigured on a per user basis or per radio bearer basis (EES) using RRC or 
MAC signalling (EES). The use of System Information should also be considered for the initial setup of default buffer 
reporting criteria (on a per cell basis). Constraints on how often uplink buffer reports are signalled from the UEs can be 
specified by the network to limit the overhead from sending the reports in the uplink. 

It is EES whether additional measurement information is required to support the classification of UEs between localised 
and distributed resource allocation. 

It is EES whether additional measurement information is required to support cell center / cell-edge resource subdivision. 

1 1 .4 Rate Control of GBR, MBR, and AMBR 

11.4.1 Downlink 

The eNB enforces the downhnk MBR associated with a GBR bearer and the downlink AMBR associated with a group 
of Non-GBR bearers. 

11.4.2 Uplink 

The UE has an uplink rate control function which manages the sharing of uplink resources between radio bearers. RRC 
controls the uplink rate control function by giving each bearer a priority and a prioritised bit rate (PBR). In addition, an 
MBR per GBR bearer and an AMBR per group of Non-GBR bearers is also provided. The values signalled may not be 
related to the ones signalled via SI to the eNB. 

The uplink rate control function ensures that the UE serves its radio bearer(s) in the following sequence: 

1 . All the radio bearer(s) in decreasing priority order up to their PBR; 

2. All the radio bearer(s) in decreasing priority order for the remaining resources assigned by the grant and the 
function ensures that the MBR and AMBR are not exceeded. 

NOTE: In case the PBRs are all set to zero, the first step is skipped and the radio bearer(s) are served in strict 
priority order: the UE maximises the transmission of higher priority data. 

If more than one radio bearer has the same priority, the UE shall serve these radio bearers equally. 
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12 



DRX in RRC CONNECTED 



In order to enable reasonable UE battery consumption, DRX in E-UTRAN is characterised by the following: 

- Per UE mechanism (as opposed to per radio bearer); 

No RRC or MAC substate to distinguish between different levels of DRX; 

- Available DRX values are controlled by the network and start from non-DRX up to x seconds. Value x may be as 
long as the paging DRX used in LTE_IDLE. Detailed values are FES; 

Measurement requirement and reporting criteria can differ according to the length of the DRX interval i.e. long 
DRX intervals may experience more relaxed requirements; 

The network may send a threshold indicating to the UE that it does not need to make measurements of 
neighbouring cells if the radio quality of the serving cell (exact definition of the radio quality and possible 
dependency on DRX value is EES) is above the threshold; 

- Irrespective of DRX, UE may use first available RACH opportunity to send an UL measurement report; 

- Immediately after sending a measurement report, the UE may change its DRX. This mechanism would be pre- 
configured by the eNB ; 

- HARQ operation related to UL data transmission is independent of DRX operation. Whether HARQ operation of 
DL data is independent of DRX operation is EES; 



13 QoS 



13.1 QoS concept and bearer service architecture 

The SAE bearer service layered architecture is depicted in Eigure 13.1 below: 

< SAE X Internet 



-E-UTRAN- 



->^ 



-EPC- 



UE 



eNB 



GW 



End-to-end Service 



SAE Bearer Service 



SAE Radio BS SAE Access BS 



Pliys. Radio BS Physical BS 



Radio 



S1 



Peer 
Entity 



External BS 



Gi 



Figure 13.1 : SAE Bearer Service Architecture 

The SAE Bearer Service is used to provide the edge-to-edge QoS for service data flows. The SAE bearer consists of a 
SAE radio bearer and a SAE access bearer. The SAE Radio Bearer Service provides the transport of the SAE Bearer 
Service data units between eNB and UE according to the SAE QoS profile associated with each SAE bearer. The SAE 
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Access Bearer Service provides the transport of the S AE Bearer Service data units between S AE Gateway and eNB 
according to the SAE QoS profile associated with each SAE bearer. 

With respect to E-UTRAN, the following principles apply: 

- There is a one-to-one mapping between an SAE Bearer and an SAE Radio Bearer; 

- There is a one-to-one mapping between an SAE Radio Bearer and a logical channel. 

13.2 Resource establishment and QoS signalling 
14 Security 

Note: Security functions needs to be re-discussed as a result of moving the PDCP from SAE Gateway down to 
the eNB. 

1 4. 1 Overview and Principles 

The following principles apply to RRC security: 

- The RRC keys are cryptographically separated from the CN keys used for NAS and end user data protection 
(making it impossible to use the RRC key to figure out a CN key). 

- The RRC keys are either generated directly by a NAS (CN/UE) level AKA procedure, or derived in the CN/UE 
from key material that was generated by a NAS (CN/UE) level AKA procedure. 

- The RRC keys are sent from the CN to the eNB when the UE is entering LTE_ACTIVE state (i.e. during RRC 
connection or SI context setup). 

Key material for the RRC keys is sent between the eNBs during LTE_ACTIVE intra-E-UTRAN mobility. 

- A sequence number is used as input to the ciphering and integrity protection of RRC. A given sequence number 
must only be used once for a given RRC key (except for identical re-transmission). The same sequence number 
can be used for both ciphering and integrity protection. 

- A hyper frame number (HEN) (i.e. an overflow counter mechanism) is used in the eNB and UE in order to limit 
the actual number of sequence number bits that is needed to be sent over the radio with each RRC message. The 
HEN needs to be synchronized between the UE and eNB. 

14.2 Security termination points 

The table below describes the security termination points. 
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Table 14.2 Security Termination Points 





Ciphering 


Integrity Protection 


NAS Signalling 


Required and terminated in MME 


Required and terminated in MME 


U-Plane Data 


Required and terminated in eNB 
(N0TE1) 


Not Required 
(NOTE 3) 


RRC Signalling (AS) 


Required and terminated in eNB 
(NOTE 2) 


Required and terminated in eNB 
(NOTE 2) 


MAC Signalling (AS) 


Note required (NOTE 4) 


Note required (NOTE 4) 


NOTE 1 : The protocol stack layer in which the ciphering takes place is FFS. The activation/deactivation of 

ciphering of the U-Plane is not controlled by the eNB. 
NOTE 2: Key set for RRC protection cannot be used to derive NAS and user-plane keys. 
NOTE 3: Integrity protection for U-Plane is not required and thus it is not supported between UE and SAE 

Gateway or for the transport of user plane data between eNB and SAE Gateway on S1 interface. 
NOTE 4: SA3 needs to further study on whether buffer status reports from UEs to the eNBs in MAC layer need to 

be protected. 



15 



MBMS 



1 5.1 MBMS control & functions 



15.2 MBMS transmission 



16 Radio Resource Management aspects 

The purpose of radio resource management (RRM) is to ensure the efficient use the available radio resources and to 
provide mechanisms that enable E-UTRAN to meet radio resource related requirements identified in sub-clause 10 of 
3GPP TR 25.913 [2]. In particular, RRM in E-UTRAN provides means to manage (e.g. assign, re-assign and release) 
radio resources taking into account single and multi-cell aspects. 

16.1 RRM functions 

16.1.1 Radio Bearer Control (RBC) 

The establishment, maintenance and release of Radio Bearers involve the configuration of radio resources associated 
with them. When setting up a radio bearer for a service, radio bearer control (RBC) takes into account the overall 
resource situation in E-UTRAN, the QoS requirements of in-progress sessions and the QoS requirement for the new 
service. RBC is also concerned with the maintenance of radio bearers of in-progress sessions at the change of the radio 
resource situation due to mobility or other reasons. RBC is involved in the release of radio resources associated with 
radio bearers at session termination, handover or at other occasions. 

RBC is located in the eNB. 

16.1.2 Radio Admission Control (RAG) 

The task of radio admission control (RAC) is to admit or reject the establishment requests for new radio bearers. In 
order to do this, RAC takes into account the overall resource situation in E-UTRAN, the QoS requirements, the priority 
levels and the provided QoS of in-progress sessions and the QoS requirement of the new radio bearer request. The goal 
of RAC is to ensure high radio resource utilization (by accepting radio bearer requests as long as radio resources 
available) and at the same time to ensure proper QoS for in-progress sessions (by rejecting radio bearer requests when 
they cannot be accommodated). 
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RAC is located in the eNB. 

16.1.3 Connection Mobility Control (CMC) 

Connection mobility control (CMC) is concerned with the management of radio resources in connection with idle or 
active mode mobility. In idle mode, the cell reselection algorithms are controlled by setting of parameters (thresholds 
and hysteresis values) that define the best cell and/or determine when the UE should select a new cell. Also, E-UTRAN 
broadcasts parameters that configure the UE measurement and reporting procedures. In active mode, the mobility of 
radio connections has to be supported. Handover decisions may be based on UE and eNB measurements. In addition, 
handover decisions may take other inputs, such as neighbour cell load, traffic distribution, transport and hardware 
resources and Operator defined policies into account. 

CMC is located in the eNB. 

16.1.4 Dynamic Resource Allocation (DRA) - Packet Scheduling (PS) 

The task of dynamic resource allocation (DRA) or packet scheduling (PS) is to allocate and de-allocate resources 
(including buffer and processing resources and resource blocks (i.e. chunks)) to user and control plane packets. DRA 
involves several sub-tasks, including the selection of radio bearers whose packets are to be scheduled and managing the 
necessary resources (e.g. the power levels or the specific resource blocks used). PS typically takes into account the QoS 
requirements associated with the radio bearers, the channel quality information for UEs, buffer status, interference 
situation, etc. DRA may also take into account restrictions or preferences on some of the available resource blocks or 
resource block sets due to inter-cell interference coordination considerations. 

DRA is located in the eNB. 

16.1.5 Inter-cell Interference Coordination (ICIC) 

Inter-cell interference coordination has the task to manage radio resources (notably the radio resource blocks) such that 
inter-cell interference is kept under control. ICIC is inherently a multi-cell RRM function that needs to take into account 
information (e.g. the resource usage status and traffic load situation) from multiple cells. The preferred ICIC method 
may be different in the uplink and downlink. 

ICIC is located in the eNB. 

16.1.6 Load Balancing (LB) 

Load balancing has the task to handle uneven distribution of the traffic load over multiple cells. The purpose of LB is 
thus to influence the load distribution in such a manner that radio resources remain highly utilized and the QoS of in- 
progress sessions are maintained to the extent possible and call dropping probabilities are kept sufficiently small. LB 
algorithms may result in hand-over or cell reselection decisions with the purpose of redistribute traffic from highly 
loaded cells to underutilized cells. 

LB is located in the eNB. 

16.1.7 Inter-RAT Radio Resource Management 

Inter-RAT RRM is primarily concerned with the management of radio resources in connection with inter-RAT 
mobility, notably inter-RAT handover. At inter-RAT handover, the handover decision may take into account the 
involved RATs resource situation as well as UE capabilities and Operator policies. The importance of Inter-RAT RRM 
may depend on the specific scenario in which E-UTRAN is deployed. Inter-RAT RRM may also include functionality 
for inter-RAT load balancing for idle and active mode UEs. 
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16.2 RRM architecture 

16.2.1 Centralised Handling of certain RRM Functions 

16.2.2 De-Centralised RRM 

16.2.3 Load balancing control 

17 RF aspects 

17.1 Spectrum deployments 



18 UE capabilities 



RRC signalling carries RRC capability and NAS signalling carries NAS capability. Some capability information may be 
stored in the EPC. In the uplink, some capability information may be sent early in e.g. 
RRC_CONNECTION_REQUEST. In the downlink, inquiry procedure of the UE capability may be supported. 



19 SI Interface 
19.1 SI User plane 

The SI user plane interface (Sl-U) is defined between the eNB and the SAE GW. The Sl-U interface provides non 
guaranteed delivery of user plane PDUs between the eNB and the SAE GW. The user plane protocol stack on the S 1 
interface is shown in Figure 19.1. The transport network layer is built on IP transport and GTP-U is used on top of 
UDP/IP to carry the user plane PDUs between the eNB and the SAE GW. 



User plane PDUs 



GTP-U 



UDP 



IP 



Data link layer 



Physical layer 



Figure 19.1 : SI Interface User Plane (eNB-SAE GW) 
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19.2 S1 Control Plane 

The SI control plane interface (Sl-MME) is defined between the eNB and the MME. The control plane protocol stack 
of the SI interface is shown on Figure 19.2. The transport network layer is built on IP transport, similarly to the user 
plane but for the reliable transport of signalling messages SCTP is added on top of IP. The application layer signalling 
protocol is referred to as Sl-AP (SI Application Protocol). 



Sl-AP 



SCTP 



IP 



Data link layer 



Physical layer 



Figure 19.2: SI Interface Control Plane (eNB-MME) 

The SCTP layer provides the guaranteed delivery of application layer messages. 

In the transport IP layer point-to-point transmission is used to deliver the signalling PDUs. 

A single SCTP association per Sl-MME interface instance shall be used with one pair of stream identifiers for Sl- 
MME common procedures. Only a few pairs of stream identifiers should be used for Sl-MME dedicated procedures. 
The upper limit for the number of stream identifiers for dedicated procedures is FES and will be decided during the 
stage 3 work. 

MME communication context identifiers that are assigned by the MME for Sl-MME dedicated procedures and eNB 
communication context identifiers that are assigned by the eNB for Sl-MME dedicated procedures shall be used to 
distinguish UE specific Sl-MME signalling transport bearers. The communication context identifiers are conveyed in 
the respective Sl-AP messages. 

19.2.1 SI Interface Functions 

Note: The following list of SI functions reflects the status of agreements in RAN3, might be extended in 
forthcoming meetings. 

- SAE Bearer Service Management function: 

- Setup, release. 

- Mobility Functions for UEs in LTE_ACTIVE: 

Intra-LTE Handover; 

- Inter-3GPP-RAT Handover. 

- S 1 Paging function: 

- NAS Signalling Transport function; 

- S 1 -interface management functions : 

Error indication. 

- Network Sharing Function; 
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- Roaming and Area Restriction Support function; 

- NAS Node Selection Function; 

- Initial Context Setup Function. 

19.2.1.1 SI Paging function 

The paging function supports the sending of paging requests to all cells of the TA(s) the UE is registered. 

Paging requests are sent to the relevant eNodeBs according to the mobility information kept in the UE's MM context in 
the serving MME. 

1 9.2.1 .2 SI UE Context Management function 

In order to support UEs in LTE_ACTIVE, UE contexts need to be managed, i.e. established and released in the eNodeB 
and in the EPC to support user individual signalling on S 1 . 

1 9.2.1 .3 Initial Context Setup Function 

NOTE: The naming of the function/procedure is left to be FES. 

The Initial Context Setup function supports the establishment of the necessary overall initial UE Context including S AE 
Bearer context, Security context, roaming restriction, UE capability information, UE SI signalling connection ID, etc. 
in the eNB to enable fast Idle-to-Active transition. 

In addition to the setup of overall initial UE Contexts, Initial Context Setup function also supports the piggy-backing of 
the corresponding NAS messages. Initial Context Setup is initiated by the MME. 

19.2.2 S1 Interface Signalling Procedures 

Note: The following list of SI procedures reflects the status of agreements in RAN3, might be extended in 
forthcoming meetings. 

- SAE Bearer signalling procedures: 

- SAE Bearer Setup procedure; 

- SAE Bearer Release procedure (EPC initiated); 

- SAE Bearer Release procedure (eNB initiated). 

- Handover signalling procedures; 

- Paging procedure; 

- NAS transport procedure: 

UL direction (Initial UE); 
DL direction (Direct Transfer). 

- Error Indication procedure: 

E-UTRAN initiated error indication procedure; 

- EPC initiated error indication procedure. 

- Initial Context Setup procedure; 
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19.2.2.1 Paging procedure 



eNB 


[SlAP] PAGING 


MME 














Paging Response (NAS means) 


h 













Figure 19.2.2.1: Paging procedure 

The MME initiates the paging procedure by sending the PAGING message to each eNB belonging to the tracking 
area(s) in which the UE is registered. 

The paging response back to the MME is initiated on NAS layer and is sent by the eNodeB based on NAS -level routing 
information. 

19.2.2.2 SI UE Context Release procedure 

The S 1 UE Context Release procedure causes the eNB to remove all UE individual signalling resources and the related 
user data transport resources. This procedure is initiated by the EPC and may be triggered on request of the serving 
eNB. 



19.2.2.2.1 



SI UE Context Release (EPC triggered) 



eNB 



[SlAP] SI UE Context Release Command 



[SlAP] SI UE Context Release Complete 



EPC 



Figure 19.2.2.2.1 : SI UE Context Release procedure (EPC triggered) 

The EPC initiates the UE Context Release procedure by sending the S 1 UE Context Release Command towards 
the E-UTRAN. The eNodeB releases all related signalling and user data transport resources. 

The eNB confirms the SI UE Context Release activity with the SI UE Context Release Complete message. 

In the course of this procedure the EPC releases all related resources as well, except context resources in the 
EPC for mobility management and the default SAE Bearer configuration. 



19.2.2.2.2 



SI UE Context Release Request (eNB triggered) 



The S 1 UE Context Release Request procedure is initiated for E-UTRAN internal reasons and comprises the following 
steps: 

- The eNB sends the SI UE Context Release Request message to the EPC. 

- The EPC triggers the EPC initiated UE context release procedure. 
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eNB 


[SlAP] SI UE Context Release Request 
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[SlAP] SI UE Context Release Command 
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[SlAP] SI UE Context Release Complete 
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Figure 19.2.2.2.2: SI UE Context Release Request procedure (eNB triggered) 
and subsequent SI UE Context Release procedure (EPC triggered) 

1 9.2.2.3 Initial Context Setup procedure 

NOTE: The naming of the function/procedure is left to be FES. 

The Initial Context Setup procedure establishes the necessary overall initial UE context in the eNB in case of an Idle-to 
Active transition. The Initial Context Setup procedure is initiated by the MME. 

The Initial Context Setup procedure comprises the following steps: 

- The MME initiates the Initial Context Setup procedure by sending INITIAL CONTEXT SETUP REQUEST to 
the eNB. This message may include general UE Context (e.g. security context, roaming restrictions, UE 
capability information, UE SI signalling connection ID, etc.), SAE bearer context (Serving SAE-GW TEID, 
QoS information), and may be piggy-backed with the corresponding NAS message. 

- Upon receipt of INITIAL CONTEXT SETUP REQUEST, the eNB setup the context of the associated UE, and 
perform the necessary RRC signalling towards the UE, e.g. Radio Bearer Setup procedure. 

- The eNB responds with INITIAL CONTEXT SETUP COMPLETE to inform a successful operation, and with 
INITIAL CONTEXT SETUP FAILURE to inform an unsuccessful operation. 



UE 
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RACH preamble 
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RRC: Connection Request 
(NAS: Service Request) 
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RRC: Radio Bearer Setup 
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S1- AP: INITIAL UE MESSAGE (FFS) 

+ NAS: Service Request 
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MME 



,S1-AP: INITIAL CONTTEXT SETUP REQUEST 



'^+ (NAS message) 
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+ Bearer Setup (Serving SAE- GWTBD, QoS 
profile) 

S1- AP: INITIAL CONTEXT SETUP COMPLETE 



+ eNB UE signalling connection ID 
+ Bearer Setup Confirm (eNB TEID) 



Figure 19.2.2.3: Initial Context Setup procedure (highlighted in blue) in Idle-to- Active procedure 
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20 X2 Interface 



20.1 User Plane 



20.2 Control Plane 

The X2 control plane interface (X2-CP) is defined between two neighbour eNBs. The control plane protocol stack of 
the X2 interface is shown on Figure 20.2 below. The transport network layer is built on SCTP on top of IP. The 
application layer signalling protocol is referred to as X2-AP (X2 Application Protocol). 

Note: Exact naming of application protocol FFS. 



X2-AP 



SCTP 



IP 



Data link layer 



Physical layer 



Figure 20.2: X2 Interface Control Plane 

A single SCTP association per X2-C interface instance shall be used with one pair of stream identifiers for X2-C 
common procedures. Only a few pairs of stream identifiers should be used for X2-C dedicated procedures. The upper 
limit for the number of stream identifiers for dedicated procedures is FFS and will be decided during the stage 3 work. 

Source-eNB communication context identifiers that are assigned by the source-eNB for X2-C dedicated procedures, and 
target-eNB communication context identifiers that are assigned by the target-eNB for X2-C dedicated procedures, shall 
be used to distinguish UE specific X2-C signalling transport bearers. The communication context identifiers are 
conveyed in the respective X2AP messages. 

20.2.1 X2-CP Functions 

The X2AP protocol supports the following functions: 

- Intra LTE- Access-System Mobility Support for UE in LTE_ACTIVE: 
Context transfer from source eNB to target eNB; 
- Control of user plane tunnels between source eNB and target eNB. 
General X2 management and error handling functions: 
Error indication. 

20.2.2 X2-CP Procedures 

The elementary procedures supported by the X2AP protocol are listed in Table 20.2.2 below: 
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Table 20.2.2: X2-CP Procedures 



Elementary 
Procedure 


Initiating 
Message 


Response Message of 
Successful Outcome 


Response Message of 
Unsuccessful Outcome 


Description & comments 


Handover 
Preparation 


HANDOVER 
REQUEST 


HANDOVER 
SUCCESS 


HANDOVER FAILURE 


Used by source eNB to request a hando 
the target eNB 


Release 
Resource 


RELEASE 
RESOURCE 






Used by the target eNB to signal to sour 
eNB that control plane resources for the 
handed over UE context can be release 


Error 
Indication 


ERROR 
INDICATION 






Used by the eNB to report errors in a re 
message provided they cannot be repor 
an appropriate response message. 



Note: this initial list might be extended. 



21 System and Terminal complexity 

21 .1 Overall System complexity 

21 .2 Physical layer complexity 

21.3 UE complexity 



22 Support for self-configuration and self-optimisation 
22.1 Definitions 

This concept includes several different functions from eNB activation to radio parameter tuning. Figure 19.1 is a basic 
framework for all self-configuration /self-optimization functions. 

Self -configuration process is defined as the process where newly deployed nodes are configured by automatic 
installation procedures to get the necessary basic configuration for system operation. 

This process works in pre-operational state. Pre-operational state is understood as the state from when the eNB is 
powered up and has backbone connectivity until the RF transmitter is switched on. 

As described in Figure 21.1, functions handled in the pre-operational state like: 

- Basic Setup and 

- Initial Radio Configuration 

are covered by the Self Configuration process. 

NOTE: depending on the final chosen functional distribution in RAN, the feasibility of following items should be 
studied e.g.: 

- To obtain the necessary interface configuration; 

- Automatic registration of nodes in the system can be provided by the network; 

- Alternative possibilities for nodes to obtain a valid configuration; 
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- The required standardization scope. 

Self-optimization process is defined as the process where UE & eNB measurements and performance measurements 
are used to auto-tune the network. 

This process works in operational state. Operational state is understood as the state where the RF interface is 
additionally switched on. 

As described in Figure 21.1, functions handled in the operational state like: 

- Optimization / Adaptation 

are covered by the Self Optimization process. 

NOTE: depending on the final chosen functional distribution in RAN the feasibility of following items should be 
studied e.g.: 

- The distribution of data and measurements over interfaces relevant to RAN3; 

- Functions/entities/nodes in charge of data aggregation for optimization purpose; 
Dependencies with O&M and O&M interfaces, in the self optimization process; 

- The required standardization scope. 

The architecture of logical self-configuration/optimization functionality is FES. 



eNB power on 
\^ (or cable connected) y 



(A) Basic Setup 



Self-Configuration 
(pre-operational state) 



j-1 : configuration of IP address 
and detection of 0AM 



a-2 : authentication of eNB/NW 



a-3 : association to aGW 



3-4 : downloading of eNB software 
(and operational parameters) 



Se_lf-Optimis_ation 
(operational state) 



(B) Initial Radio 
Configuration 



b-1 : neighbour list configuration 



b-2 : coverage/capacity related 
parameter configuration 



(C) Optimization / 
Adaptation 



c-1 : neighbour list optimisation 



c-2 : coverage and capacity control 



Figure 21.1: Ramifications of Self-Configuration /Self-Optimization functionality 
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23 Others 

23.1 Support for real time IMS services 
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Annex A (informative): 
NAS Overview 



This subclause provides for information an overview on services and functions provided by the NAS control protocol.. 

A.1 Services and Functions 

The main services and functions of the NAS sublayer include: 

- SAE Bearer control (see 3GPP TR 23.882 [6]); 
LTE_IDLE mobility handling; 

- Paging origination; 

- Configuration and control of Security. 

A.2 NAS protocol states & state transitions 

The NAS control protocol uses the following states: 
LTE_DETACHED: 

- No RRC entity. 
LTEJDLE: 

- RRCJDLE State; 

Some information is stored in the UE and in the network: 

- IP address, etc; 

- Security association (keys, etc); 

- UE capability information (FES); 

- Radio Bearers (EES); 

- State transition decided in eNB or EPC (EES); 
LTE_ACTIVE: 

- RRC_CONNECTED State; 

- State transition decided in eNB or EPC (EES); 

The following figure reflects how the NAS states relate to the RRC: 
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Inactivity 

- Release C-RNTI 

- Allocate DRX for PCH 



Perform "Registration" 

- Allocate C-RNTI, TA-ID, IP addr 

- Perform Authentication 

- Establish security relation 



r Power- Up) 























LTE IDLE 


LTE ACTIVE 


- 


LTE DETACHED 


™ 


RRC: RRCJDLE 




RRC:RRC_CONNECIbU 


- 


RRC: NULL 


™ 


Context in network: 

- Includes information to enable fast 
transition to LTE_ACTIVE (e.g. 
security key information) 

Allocated UE-ld(s): 
-IMSI 

- ID unique in Tracking Area (TA-ID) 
- 1 or more IP addresses 




RRC Context in network: 

- Includes all information necessary for 
communication 

Allocated UE-ld(s): 
-IMSI 

- ID unique in Tracking Area (TA-ID) 

- ID unique in cell (C-RNTI) 
- 1 or more IP addresses 


™ 


RRC Context in network: 
- Does not exist 

Allocated UE-ld(s): 
-IMSI 


™ 


UE position: 

- Known by network at Tracking Area 
(TA) level 

Mobility: 

- Cell reselection 




UE position: 

- Known by network at cell level 

Mobility: 

- Handover 


- 


UE position: 

- Not known by network 

Mobility 

- PLMN/Cell selection 


: 


DL activity: 

- UE is configured with DRX period 




DL/UL activity: 

- UE may be configured with DRX/DTX 
periods 




DL/UL activity: 
- None 


™ 
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cate C-RNTI 


Chanae of PLMN/dereaistration 
- Deallocate C-RNTI, TA-ID, IP adc 





Timeout of periodic TA-update 
- Deallocate TA-ID, IP address 

Figure A.2: E-UTRAN RRC protocol states 

NOTE: The applicability of the ID unique in Tracking Area (TAID) in LTE_DET ACHED is FFS. 

The UE context in the EPC will discriminate the 3 states. The UE context in the eNB will only exist in the 
LTE ACTIVE state. 
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Annex B (informative): 
MAC and RRC Control 



The E-UTRA supports control signalling in terms of MAC control signalling (L1/L2 control channel and MAC control 
PDU) and RRC control signalling (RRC message). 



B.1 Difference between MAC and RRC control 

The different characteristics of MAC and RRC control are summarized in the table below. 

Table B.1 : Summary of the difference between MAC and RRC control 





MAC control 


RRC control 


Control entity 


MAC 


RRC 


Signalling 


L1/L2 control channel 


MAC control PDU 


RRC message 


Signalling reliability 


~ 10'^ (no retransmission) 


- 10"^ (after HARQ) 


- 10"^ (after ARQ) 


Control delay 


Very short 


Short 


Longer 


Extensibility 


None or very limited 


Limited 


High 


Security 


No integrity protection 
No ciphering 


No integrity protection 
No ciphering 


Integrity protected 
Ciphering (FFS) 



The main difference between MAC and RRC control lies in the signalling reliability. Due to the signalling reliability, 
signalling involving state transitions and radio bearer configurations should be performed by RRC. Basically, all 
signalling performed by RRC in UTRA should also be performed by RRC also for E-UTRA. 



B.2 Classification of MAC and RRC control functions 

The table below illustrates the classification of MAC and RRC control functions for E-UTRAN. 
Table B.2: Classification of MAC and RRC control functions 





Controlled configuration/parameters 


MAC 

control 

signalling 


L1/L2 
control 
channel 


Short-lived (PRB) and dynamic (MCS) allocation 
Long-lived (PRB) and fixed (MCS) allocation (FFS) 
Timing Advance (FFS) 


MAC control 
PDU 


Timing Advance (FFS) 

RLC related control PDU (FFS) 


RRC control 
signalling 


RRC 
message 


Long-lived (PRB) and fixed (MCS) allocation (FFS) 

Activation/deactivation of long-lived (PRB) and/or fixed (MCS) allocation (FFS) 

TTI configuration for variable TTI length control (FFS) 

Static parameter configuration for UE inactivity control within RRC ACTIVE (e.g. 

DRX/DTX periods) 
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Annex C (informative): 
System Information 



This annex provides an overview of the classification and division of system information between static and flexible 
parts. Considerations about dedicated distribution of system information are also included. 



C.1 SI classification 

Five categories are identified for system information classification: 

1. Information valid across multiple cells; 

2. Information needed at cell/PLMN search; 

3. Information needed prior to cell camping; 

4. Information needed before cell access; 

5. Information needed while camping on a cell. 

From UEs' point of view, the information that is needed at cell selection and prior to camping are very similar. Before a 
UE can camp on a cell, it needs to know if the access is allowed in that cell. Thus it would be very beneficial to know 
all access restrictions already at cell search phase. 

C.1 .1 Information valid across multiple cells 

The pieces of information that can be valid across multiple cells are: 

- A-GNSS assistance data; 

- PLMN identity (ies); 

- Tracking area identity; 

Note: the above text will be revised if it is agreed that a cell can be a member of more than one tracking area. 

- Predefined configuration information; 

System Frame Number if it does not change from cell to cell (in case of synchronized network); 

- Some measurement/mobility information (FFS). 

C.1 .2 Information needed at cell/PLMN search 

In order to support full mobility within the serving frequency layer, the UEs need to perform cell search rather often and 
thus it is seen very important that the information needed in cell search phase is readily available, thereby improving 
cell search times and minimizing UE power consumption. If system information decoding is needed for identifying a 
cell, fast system information reception is needed in order to avoid too long identification times. For optimising PLMN 
search and make PLMN search fast and non-complex, the information needed for PLMN search should be easily 
available. The pieces of information that are needed at cell/PLMN search are: 

- PLMN identity (ies): in order to acquire information to which PLMN the cell belongs, UEs need to receive 
PLMN identity (ies); 

NOTE: There may be multiple PLMN identities for one cell. 

- Measurement cell identity (FFS): there needs to be a cell identity in the system information, in order to allow 
UEs to identify the cell reliably for measurement purposes. 
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NOTE: UEs may identify the cell also based on the reference sequence detection; 
There is another cell identity that identifies the cell within e.g. PLMN. 

NOTE: UEs may have to check possible cell access restrictions before selecting cell/PLMN; 
For cell/PLMN search UEs might need some LI parameters. 

C.1 .3 Information needed prior to cell camping 

Before a UE can camp on a cell, it needs to know any access related parameters in order to avoid camping on cells 
where access is forbidden. Thus prior to camping on a cell, a UE needs to know the following information: 

- Any cell access restriction parameters, e.g.: 

- Tracking area identity: if the forbidden TA concept is adopted from legacy systems, then the UE needs to 
know whether the cell belongs to such forbidden TA. 

Note: the above text will be revised if it is agreed that a cell can be a member of more than one tracking area. 

- Cell barring status and cell reservation status (FES if needed per PLMN): the UE needs to know whether the 
cell is barred or reserved in order to avoid camping on a barred cell. Possibly also barring time might be 
needed in order to avoid UE to poll barring time frequently from the system information. Another option is 
that barring status is indicated also in the neighbour cell list. 

- Radio access limitation parameters: 

- Any radio condition parameters that limit the access to the cell e.g. similar to GSM Cl/S criteria; 

- It is FES if we need to have some band information indication also, in order to allow UEs to check 
possible band support before camping on the cell. 

NOTE: UE may need some LI parameters prior to camping. 

C.1 .4 Information needed prior to cell access 

Once a UE has camped on a cell, the information needed prior to cell access (transmission/reception) includes at least: 

- System Frame Number (SEN) (FES) 

- SEN is probably needed by the UE to understand the scheduling parameters (e.g. scheduling information for 
secondary SI, RACH, PCH, E-MBMS etc.) 

- LI information, example set of needed LI parameters: 

Note: RANI needs to define what parameters are needed at this phase. 

- Carrier Bandwidth: FES if separate bandwidths for UL and DL are needed; 

- Carrier center frequency (FES); 

- Cyclic Prefix parameters: in order to decode DL-SCH UE needs to know the CP length arrangements; 

MIMO related parameters: in order to take advantage of the multi-antenna transmissions like MIMO, the UE 
needs to know parameters of number of TX antennas, DL/UL pre-coding matrices, etc.; 

- Band Information: may be needed if the same DL carrier frequency has variable UL carrier frequency; 

- L1/L2 signalling channel structure parameters: if L1/L2 signalling channel has variable configurations, the 
UE may need to know its channel structure at least partly. L1/L2 signalling is crucial to receive any 
allocation information. If Random Access Response is transmitted without L1/L2 signalling (e.g. 
synchronous transmission with Random Access Preamble), this information might not be required; 

- RACH parameters (needed by the UE to start usage of RACH): 
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- RACH scheduling information: UE needs to know where in time (sub-frame) and frequency (Physical 
Resource Units) the RACH channel is located; 

RACH sequences: UE needs to know the RACH set of sequences to choose from. The sequences may not be 
fully of equal meaning (e.g. CQI can be classified for the sequences in a specific way); 

- Access class restrictions: access class restrictions might be needed to limit the number of possible UEs using 
RACH; 

- Persistence values: possible persistence value scheme parameters are needed for RACH usage; 

- Other parameters related to RACH: UE needs to know the timers and parameters related to RACH e.g. how 
often the UE retransmits RACH and how many times the retransmission is allowed etc; 

- RACH power control parameters: UE needs to know parameters related to UL power control. 

C.1 .5 Information needed while camping on a cell 

When a UE has camped on a cell, it needs to continue measuring the neighbouring cells in order to stay camped. The 
pieces of information required for that are: 

- Measurement parameters: 

- In order for the UE to start mobility procedures, it needs to receive parameters e.g. of reporting periods, 
reporting event parameters, time to trigger etc. UEs in RRC_IDLE state need cell reselection parameters. 
UEs in RRC_CONNECTED state need parameters of the neighbour cells e.g. for handover and for error 
recovery cases. 

- Neighbour cell lists are needed to start neighbour cell measurements. UEs in different states may use 
different sets of neighbour cell lists. Neighbour cell list may contain following parameters: 

- Some LI parameters: FES what parameters are needed in the neighbour cell list; 

- All information that is needed for camping: see sub-clauses C.2.2 and C.2.3 (FES); 

- Synchronization information: indicating whether the neighbouring cell is synchronized to the current cell 
i.e. the cell sending the neighbour cell list (EES); 

- PLMN identity(ies) & tracking area identity (EES); 

Note: the above text will be revised if it is agreed that a cell can be a member of more than one tracking area. 

- Other 3GPP RAT information: e.g. neighbour cell information of GERAN/UTRAN cells; 
Information of non-3GPP access systems (e.g. WIMAX). 

- Secondary NAS parameters: 

An y NAS parameters that were not presented earlier e.g. cell identity uniquely identifying cell within wide 
area e.g. PLMN; 

Cell identity (PLMN level) (EES if this should be in category "Information needed prior to cell access"). 

- Secondary UE timer values: any timer values that affect UE's behaviour. 

- Paging parameters: UEs in LTE_IDLE state need to receive paging parameters e.g. DRX periods and scheduling. 

- Clock time (EES): the network might send system clock in order to let UEs update their clock time e.g. in the 
user interface; 

- MBMS service parameters: any parameters needed for MBMS reception e.g. MBMS multiplexing parameters, 
MEMS frequency; 

NOTE: the presence of these parameters also indicate the presence of MBMS service in the cell (dedicated or 
mixed cell). 
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- Signalling Radio Bearer parameters: may be broadcasted unless they are standardized. 

C. 1 .6 Thoughts about category division 

From UEs' point of view the categories in sub-clauses C.1.2 and C.1.3 are very similar. Thus it is questionable whether 
we need to differentiate procedures between cell search/selection/camping and PLMN search. 

From UEs' point of view, the difference between the procedure for cell search during RRC_CONNECTED and the 
procedure for cell search during RRC_IDLE state maybe small. When the UE is in RRC_CONNECTED state, it 
measures the neighbour cell and executes handovers commanded by the network. 

C.2 Division of SI between static and flexible parts 

System information distribution can be classified into two distinctive parts: static and flexible. Static part is sent more 
often, say once per frame, in the cell and has quite a limited capacity for information transfer. The flexible part has 
flexible amount of scheduled resources available and thus most of the SI information is contained there. 

C.2.1 Static part 

The static parts of the System Information are: 

LI information in order to decode the rest of the information 

Note: detailed information on the required information will be defined by RANI ; 

Measurement Cell identity (FES): it may be possible that LI channels do not identify the cell. Then some Cell 
identity needs to be sent on system information part; 

- Any cell access restriction parameters e.g.: 

- Tracking area identity: if forbidden TA concept is adopted from legacy systems then UEs need to know 
whether the cell belongs to forbidden TA; 

Note: the above text will be revised if it is agreed that a cell can be a member of more than one tracking area. 

- Cell barring and cell reservation status (FES if needed per PLMN): UEs need to know whether cell is barred 
or reserved in order to avoid camping on barred cell. Possibly also barring time might be needed in order to 
avoid UEs to poll barring time frequently from the system information; 

- Radio access limitation parameters: any radio condition parameters that limit the access to the cell e.g. 
similar to GSM Cl/S criteria; 

PLMN identity(ies): in order to acquire information to which PLMN cell belongs, UEs need to receive 
PLMN identity (ies). 

NOTE: there may be multiple PLMN identities for one cell. 

Scheduling parameters: 

- All of the scheduling information of flexible part or part of scheduling information (e.g. scheduling block) of 
flexible part. If static part consists of multiple SI blocks then it may be necessary to have scheduling 
information of those blocks in the static part. 

- Scheduling block defines, from where (time and frequency resources) to decode the SI blocks of the 
scheduled flexible part. It may be possible that scheduling of scheduling block is standardized, then this 
information can be omitted from the static part. If several types of scheduling blocks are defined , 
scheduling information might be sent for each scheduling block. 

Value_tag(s): informs whether the information transmitted on the flexible part has changed. This is needed in 
order to avoid UEs from reading any unchanged information repeatedly. Another possibility is to send this 
information in L1/L2 signalling channel, but possibly it would cause too much overhead. 
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NOTE: It also is possible to include Value_tag for SI on the flexible part indicating more precisely what changes 
have occurred in the system information. 

NOTE: There may be a need for indicating changes in static part with value tag also, if static part consists of 
multiple SI blocks. 

Table C.2.1 gives an estimate of the size of the elements mentioned above. 

Table C.2.1 : Initial rough estimates for static part capacity requirement 



Information element 


Bits 


Cyclic Prefix (FFS) 


2 


Carrier BW (FFS) 


3-8 


MIMO parameters (FFS) 


2 (+3) 


Cell Id (FFS) 


9 


Tracking Area Id (+ FFS how many additional) 


[16-28] 


Cell Barring status+ possible Time of barring 


1+4 


Cell reservation status 


[2] 


Radio access limitation parameters 


12 


PLMN id(s) maximum of 5 ( 24 bits per one) - see Note 


120 


Scheduling parameters 


(12-108) 


Value Tag 


4 


SFN (FFS) 


11 



NOTE: It might not be necessary to send the Mobile Country Code part of the PLMN identity for each indicated 
PLMN to hmit the number of bits. 



C.2.2 Flexible part 



The flexible part has different types of Information Elements which require independent scheduling in order to allow 
fast enough reception and not to waste transmission capacity. For example, the requirement to receive cell access 
parameters is very different than e.g. the clock time. Thus following flexible part division should be considered: 

Scheduling block: scheduling information of the secondary part of the System Information. 

- Access parameters: 

- All parameters not present in the primary part (e.g. some LI parameters); 

- RACH parameters; 
Power control parameters; 

- Paging parameters; 

- Any timer values needed for operating in the cell and in the network. 

- Measurement related parameters: 

- Neighbour cell lists; 

- Cell selection/reselection parameters; 

NOTE: Some of these parameters are included in the static part element "Radio access limitation parameters." 

- Measurement control information; 
Non vital information: 

- Clock time; 

- Positioning (A-GNSS etc.) information; 
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- Service parameters (e.g. MBMS parameters); 

- Secondary NAS parameters. 

C.2.3 Information whose location is FFS 

The location of the following information is FFS: 

- System Frame Number: SFN might be needed very fast i.e. for HO purposes. SFN might be needed also for 
decoding scheduling block parameters, but on the other hand it might be requested not to send often changing 
information on the static part in order to be able to make time soft combining. Further investigation on the SFN 
broadcasting is thus needed. 



C.2.4 Dedicated part 



The dedicated part is embedded in the RRC message that is meant for sending System Information Elements in unicast 
mode e.g. for HO purposes, positioning purposes .... The UE needs some information for the neighbouring cell to 
access it, this is needed to limit the interruption times caused by HO execution. When a UE receives a HO COMMAND 
it needs at least following information from the target cell: 

- All information in the static part (see sub-clause C.2.1): may be received by the UE by itself; 

- Most of the information from the access parameters (see sub-clause C.2.2): is favourably delivered by dedicated 
manner via the source cell, because the UE might not have time to get all the necessary secondary SI from the 
target cell; 

System Frame Number is needed to minimize the interruption times during the HO procedure. Most probably the 
UE needs to receive (at least confirm) the SFN directly by the neighbour cell SI reading, because giving the SFN 
via source cell may cause some inaccuracy to the SFN. 
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Annex D (informative): 
IVIBMS 



D.1 MBMS control & functions 

The E-UTRAN supporting MBMS comprises eNBs and co-ordinating functions. 
The functions hosted by the eNB may be: 

Scheduling and transmission of MBMS control information; 

- Scheduling of single-cell MBMS transmissions; 
Transmission of single-cell and multi-cell MBMS services; 
Radio bearer control for MBMS. 

The co-ordinating functions may include: 
Distribution of MBMS services; 

- Co-ordination of multi-cell MBMS transmissions; 

- MBMS SAE bearer control. 

It is FFS which node in E-UTRAN performs the co-ordination functions. 

D.2 MBIVIS transmission 

A point- to-multipoint radio bearer is used to carry MBMS traffic. It is FFS whether a point-to-point radio bearer is also 
used to carry MBMS traffic or not. Improvements for single-cell MBMS transmission (e.g. HARQ) and MCS that 
would enable potential removal of p-t-p transmissions for MBMS are FFS. 

A frequency layer can be dedicated to MBMS transmissions: 

- When a cell belongs to a frequency layer dedicated to MBMS transmissions (MB MS -dedicated cell): 

- The MBMS transmission (MTCH and MCCH) occurs on MCH or DL-SCH (FFS); 
No uplink or counting mechanism supported; 

- No support for unicast data transfer in the cell; 

- The occurrence of paging messages on the frequency layer dedicated to MBMS transmission is FFS: 

- If paging messages were allowed, the UE could answer in a non-E-UTRA cell e.g. UTRA cell (FFS); 

- The possible multi-cell p-t-m transmission with SEN operation on the MCH of the SEN area is semi- statically 
configured e.g. by O&M. 

- Single-cell p-t-m transmission is possible. 

- When a cell does not belong to a frequency layer dedicated to MBMS transmissions (MBMS/Unicast-mixed 
cell): 

- Transmission of both unicast and MBMS transmissions in the cell is done in a co-ordinated manner on DL- 
SCH and or MCH+DL-SCH (FFS); 

- The possible SEN operation on the MCH of the SEN area is semi- statically configured e.g. by O&M; or the 
SEN area is dynamic and may be based on counting mechanisms (FFS). 

- Counting is possible (FFS); 
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- P-t-p transmission on DL-SCH is FFS. 

There are two types of MBMS transmissions in E-UTRA/E-UTRAN: 

a) Single-cell transmission (no SFN operation): 

- The MBMS service, e.g. message distribution, is transmitted only on the coverage of a specific cell; 

- The MBMS service (MTCH and MCCH) may be transmitted on DL-SCH or MCH (FFS); 
Combining of MBMS transmission from multiple cells is not supported; 

- Counting for switching between p-t-p and p-t-m radio bearer may be supported (FFS); 

- The p-t-m/p-t-p switching points are either dynamically decided based on counting mechanism or semi- 
statically configured by O&M (FFS). 

b) Multi-cell transmission (SFN operation): 

- The MBMS service (MTCH and MCCH) is transmitted on MCH; 

- Combining is supported with SFN; 
Synchronous transmission. 

The BCCH indicates where the MCCH(s) are: 

One (or none) MCCH per cell for cell specific transmission; 

- MCCH(s) sent in SFN area for non-cell specific transmission. 

Having a feedback mechanism for MTCH transmission is FFS: statistical feedback, TTI based NACK or something 
else. Also is FFS if the re-transmission is a single cell transmission in all cases. 



D.3 Deployment Scenarios 



In terms of deployment scenarios of MBMS in E-UTRAN, the following alternatives can be listed: 

- Carrier type: dedicated vs. mixed carrier; 

- SFN transmission: multi-cell vs. single-cell transmission; 

- Radio bearer type: p-t-m vs. p-t-p; 

- Counting: yes or no; 

Audience measurement: yes or no; 

- ON/OFF control of MBMS service delivery: yes or no; 

- PTP / PTM radio bearer switching: yes or no; 

Table D.3 below lists the combinations of the above alternatives that are supported in E-UTRAN: 

Table D.3: MBMS Deployment Scenarios 



# 


Carrier 


Transmission 


RB 


Counting 


Comments 


1 


dedicated 


multi-cell 


p-t-m 


no 


From 1 to n cells 

Audience measurement (FFS) 


2 


mixed 


multi-cell 


p-t-m 


no 


Audience measurement (FFS) 















Note: other deployment scenarios will be included once agreed. 
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Annex E (informative): 
Drivers for Mobility Control 



Table E.l lists the drivers, limitations, and their applicability to intra- frequency, inter- frequency, and inter-RAT 
scenarios. Each driver and limitation is described in Section 2.1 and 2.2, respectively. 

Table E.1 : Drivers and limitations for mobility control and applicability to mobility scenarios. 





# 


Drivers/limitations 


Intra- 
frequency 


Inter- 
frequency 


Inter-RAT 


Drivers 


1 


Best radio condition 


X 


X 


X 


2 


Camp load balancing 




X 


X 


3 


Traffic load balancing 




X 


X 


4 


UE capability 




X 


X 


5 


Hierarchical cell structures 




X 


X 


6 


Network sharing 




X 


X 


7 


Private neworks/home cells 




X 


X 


8 


Subscription based mobility control 




X 


X 


9 


Service based mobility control 




X 


X 


10 


MBMS 




X 


X 


Limitations 


11 


UE battery saving 


X 


X 


X 


12 


Network signalling/processing load 


X 


X 


X 


13 


U-plane interruption and data loss 


X 


X 


X 


14 


0AM complexity 


X 


X 


X 



As shown in Table E.l, the applicable drivers depend on the mobility scenario, i.e., intra- frequency, inter-frequency, 
and inter-RAT: 

- Intra-frequency mobility: intra-frequency mobility is the most fundamental, indispensable, and frequent 
scenario. With the frequency reuse being one in E-UTRAN, applying any driver other than the "best radio 
condition" to intra-frequency mobility control incur increased interference and hence degraded performance. As 
such, only the "best radio condition" driver is applicable to intra-frequency mobility. Note that the exact 
definition of "intra-frequency mobility" is yet unclear, and shall be clarified with RANI. 

Inter-frequency mobility: as in UTRAN, an operator may have multiple carriers/bands for E-UTRAN working 
in parallel. The use of these frequency layers may be diverse. For example, some of these frequency layers may 
utilise the same eNB sites and antenna locations (i.e., co-located configuration), whereas some may be used to 
form a hierarchical cell structure (HCS), or even be used for private networks. Some frequency layers may 
provide MBMS services, while some may not. Moreover, E-UTRAN carriers/bands may be extended in the 
future to increase capacity. For example, as E-UTRAN gains popularity, an operator may decide to convert 
existing UTRAN carriers into E-UTRAN ones. The operator may also acquire additional carriers/bands, that are 
not necessarily contiguous. As a consequence, different UE band capabilities may coexist and different 
carriers/bands may operate at different areas within a network. The E-UTRAN standard should readily support 
such carrier/band extensions and diverse network configurations, providing flexibility and efficiency. Therefore, 
a number of drivers apply to inter- frequency mobility control, in addition to the "best radio condition" driver. 

- Inter-RAT mobility: the aspects that need to be considered for inter-RAT are similar to those for inter- 
frequency. For mobility solutions to be complete with the inter-RAT drivers, relevant updates would be 
necessary on the legacy (UTRAN/GERAN) specifications. This will add to the limitations, which are evidently 
more effective in inter-RAT. Although the drivers/limitations need to be assessed per objective RAT 
(UTRAN/GERAN), the solutions should be made common as much as possible to reduce any complexity. 

E.1 Drivers 

The drivers for mobility control are described in the following sections. 
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E.1 .1 Best radio condition 

The primary purpose of cell reselection, regardless of intra- frequency, inter-frequency, or inter-RAT, is to ensure that 
the UE camps on/connects to the best cell in terms of radio condition, e.g., path loss, received reference symbol power, 
or received reference symbol Es/IO. The UE should support measurements to suffice this aspect. For E-UTRAN cells, 
the frequency domain scheduling and channel/symbol mapping may have some implications to designing the 
measurements and reselection/reporting criteria. The UE would also have to check that the selected cell falls within the 
accesible range (in terms of signal strength and possibly also in terms of propagation delay, i.e., check if it falls within 
the dynamic range of timing advance, FES). 

E-UTRAN should support good mobility even when the radio environment changes suddenly, e.g., when the UE enters 
a tunnel or in a Manhattan-like street cell scenario. It should be discussed whether a special mechanism is needed to 
cope with such sudden changes in radio environment or it can be handled with good radio network planning practices. 
In either case, the system design should minimise any side effects of counteracting the sudden changes in the radio 
environment (e.g., ping-pongs). 

Eor inter- frequency/RAT mobility, the UE needs idle gaps to perform measurements on other frequency layers/RATs. 
In addition, for inter-RAT, E-UTRAN measurements while the UE is in another RAT (UTRAN/GERAN) need to be 
supported. It should be discussed whether in certain cases (e.g., co-located E-UTRAN cells within the same frequency 
band) the measurements can be omitted. 



E.1 .2 Camp load balancing 



This is to distribute idle state UEs among the available bands/carriers/RATs, such that upon activation, the traffic 
loading of the bands/carriers/RATs would be balanced. At least the path loss difference between different bands should 
be compensated to avoid UEs concentrating to a certain frequency layer (e.g., lower frequency bands due to the 
propagation nature). A deliberate mechanism would be necessary to avoid UEs concentrating to a certain RAT (e.g., E- 
UTRAN). Various solutions have been presented including the use of Qoffset and an approach of limiting the frequency 
layers for camping. 

For inter-RAT, this driver also includes the aspect of balancing the loading of core network nodes of different RATs. 
Nevertheless, for intra- E-UTRAN, the core network load aspect is out of scope, since MME/SAE Gateway relocation 
by itself should not cause any radio mobility procedure (but only NAS procedures like NAS ID and security updates). 

E.1 .3 Traffic load balancing 

This is to balance the loading of active state UEs, using redirection for example. In E-UTRAN, traffic load balancing is 
essential because of the shared channel nature. That is, the user throughput decreases as the number of active UEs in the 
cell increases, and the loading directly impacts on the user perception. A solution is desired that causes minimum 
impact on the user perception. This implies that inter-layer transitions are preferably done during data inactivity (e.g., 
DRX) or transition to the idle state. Although this driver is also applicable to inter-RAT, for inter-RAT, the "service 
dependent control" driver may be more dominant than the load balancing aspect. 

E.1. 4 UE capability 

As E-UTRAN bands/carriers may be extended in the future, UEs having different band capabilities may coexist within 
a network. It is also likely that roaming UEs have different band capabilities. Overlaying different RATs adds to this 
variety. The mobility solution should cope with the coexistence of various UE capabilities in an efficient manner. 

E.1 .5 Hierarchical cell structures 

As in UTRAN, hierarchical cell structures (HCS) may be utilised in E-UTRAN to cover for example, indoors and hot 
spots efficiently. It is possible that E-UTRAN is initially deployed only at hot spots, in which case this driver becomes 
essential for inter-RAT, not just for inter-frequency. Another use case would be to deploy a large umbrella cell to cover 
a vast area without having to deploy a number of regular cells, while providing capacity by the regular cells on another 
frequency. While HCS can be seen as a solution to reduce measurement and signalling loads, to optimise HCS usage, 
mobility control should take into account the UE mobility (e.g., speed). This however implies that sufficient mobility 
detection is also required. Although HCS is not addressed as a mobility driver for intra-frequency mobility, intra- 
frequency HCS deployment should not be restricted. 
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E.1 .6 Network sharing 

At the edge of a shared portion of a network, it will be necessary to direct UEs belonging to different PLMNs to 
different target cells. The mobility solutions in both idle and active states should therefore support differentiation 
between UEs of different operators. 

E.1 .7 Private networks/home cells 

Cells that are part of a sub-network should prioritise the camping on that sub-network. UEs that do not belong to private 
sub-networks should not attempt to camp or access them. Although this could be resolved by the use of forbidden TAs 
as in UTRAN, a more deliberate mechanism may be needed as some of these sub-networks could be very small, e.g., 
one home. 

E.1 .8 Subscription based mobility control 

This mobility driver aims to limit the inter-RAT mobility for certain UEs, e.g., based on subscription or other operator 
policies. The system should provide means to dissallow access on certain RATs (including E-UTRAN) as done with 
"LA reject" in legacy systems. It should be possible for the operator to trigger a subsequent UE action such as a cell or 
PLMN selection. 

E.1 .9 Service based mobility control 

An operator may have different policies in allocating frequencies to certain services. For example, the operator may 
concentrate VoIP UEs to a certain frequency layer or RAT (e.g., UTRAN or GERAN), if evaluations prove this 
effective. UEs requiring higher data rates may better be served on a frequency layer or RAT (e.g., E-UTRAN) having a 
larger bandwidth. The operator may also want to accommodate premium services on a certain frequency layer or RAT, 
that has better coverage or larger bandwidth. 

This driver is essential for inter-RAT, due to the different QoS levels provided by different RATs. The nature of the 
service being requested (e.g., QoS and traffic behaviour) should be considered in controlling mobility, so that services 
are accommodated in the best suitable RAT. Note that such service dependent control shall only be based on network 
decisions and not on UE decisions (i.e., no UE based service dependent cell reselection), except for MBMS scenarios. 

E.1.10 MBMS 

As MBMS services may be provided only in certain frequency layers, it may be beneficial/necessary to control inter- 
frequency/RAT mobility depending on whether the UE receives a particular MBMS service or not. For MBMS 
scenarios only, UE based service dependent cell reselection might be considered acceptable. This aspect also depends 
on the UE capability for simultaneous reception of MBMS and unicast. 



E.2 Limitations for mobility control 



While the issues mentioned above drive E-UTRAN towards "aggressive" mobility control, the limiting factors also 
have to be considered. The factors listed below apply to all intra-frequency, inter-frequency, and inter-RAT mobility 
scenarios. 

E.2.1 UE battery saving 

The mobility solution should not consume excessive UE battery, e.g., due to measurements, measurement reporting, 
BCH reception, or TA update signalling. This could be achieved for example by setting appropriate measurement rules 
such as S-criteria, hysteresis, and time-to-trigger. Adaptive control of some measurement/mobility parameters (e.g., 
based on DRX, cell size, or mobility) may also be considered as a countermeasure. To reduce TA update signalling, TA 
allocations can be differentiated depending on the UE speed or the mobility vector, on top of appropriate TA planning. 
Effects on additional delays (e.g., paging) should also be investigated if means such as "long DRX" are used to achieve 
these savings. 

It should be investigated together with RAN4 if a coupling between measurements accuracy and DRX (as in UTRAN) 
is also acceptable for E-UTRAN. 
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E.2.2 Network signalling/processing load 

The mobility solution should not cause excessive network signalling/processing load. This includes over-the-air 
signalling, S1/X2 signalling, and processing load at network nodes. Unnecessary handovers and cell reselections should 
be avoided, and PCH and BCH signallings, as well as dedicated signallings, should be limited. This could be achieved 
by similar countermeasures as for UE battery saving. 

E.2.3 U-plane interruption and data loss 

U-plane interruption and data loss caused by the mobility solution should be limited. The required QoS should be 
satisfied in any case. 

E.2.4 0AM complexity 

The mobility solution should not demand excessive efforts in operating/maintaining a network. For example, when a 
new eNB is added or an existing eNB fails, the mobility solution should not incur excessive efforts to set up or modify 
the parameters. Means should be studied to integrate the mobility solutions in the concept of "self-optimisation" to 
minimise manual processes. Reducing the neighbour list information in E-UTRAN would also be a countermeasure to 
this requirement. 
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